Community
Participate
Working Groups
It would be easier to grab and expand the Favorites section, if I could see the sash. (See also bug 334191).
Nayna, can you look at this one? We could either reuse Libing's sliding sash from the editor (if simple to do) or else at least make this one visible.
I took a quick pass at trying to use the eWebBorderContainer (the sliding splitter) because I would find that handy, but it was going to require more work, so I opened bug 336171
(In reply to comment #2) > I took a quick pass at trying to use the eWebBorderContainer (the sliding > splitter) because I would find that handy, but it was going to require more > work, so I opened bug 336171 Susan, I was trying to look at all the options as specified by you.. Couldn't exactly locate the code for Libing's sliding sash in the editor code. , Please provide this input. Also, do we plan to use this content pane for other widgets also. I mean like.. This left side pane has one favourites section, probably we can have some more options like we might plan to have outline section there. So, whichever user clicks on that expands and shows the list. Something like the example of Dojo AccordianContainer and AccordianPane. I just got this thought while trying to understand the code
Created attachment 189352 [details] Deleted the rule for .soria .dijitSplitterV
I have implemented the fix to make the splitter visible. The issue was that one of the rule defined in ide.css was overwriting the rule already present in the BorderContainer.css of soria theme. I have deleted that rule. In case that rule is used somewhere else also, please do let me know.
That rule was probably overridden when Libing was working on the dynamic splitter. I don't see that removing it affects the editor splitter, so we are probably okay to make changes. The thing to check when changing these styles is that the pages with dynamic splitters (such as the editor) still look as they are supposed to. But just deleting the rule causes the splitter to become light blue and there is a small white line for the splitter thumb. Instead could we override the rule to set both the splitter and the thumb color to the light gray used in the navigator's local toolbar? That way the splitter won't stand out so much. Having done that, i think you are good to commit the change.
I had updated the background color to blend with the toolbar color. I tried to use toolbar color itself but that was becoming too much prominent grey. So, I tried few options from different color values and chosen this work which looks like blending well with toolbar color and also not being very prominent. Please have a look and let me know if it is OK. BTW, how are we deciding upon color scheme for various widgets ? Any particular colors decided or doing some trials and choosing the ones which fits the best.
Created attachment 189455 [details] Added the rule to provide light gray color to splitter
Thanks, Nayna. Released fix. I think this might change again if I get a chance as part of bug 338483. But this is better than the current state. (In reply to comment #7) > BTW, how are we deciding upon color scheme for various widgets ? Any particular > colors decided or doing some trials and choosing the ones which fits the best. We have a graphic designer looking at the overall color schemes and advising us. But when we don't have that guidance, we do the trial and error as you suggest. I have some mockups from the designer that show a very thin gray splitter, and then it fattens up on hover. That is what I hope to implement this week.
Created attachment 190571 [details] "shash" comes over the table Nayna, try to catch the sash and move it side to side. The sash moves over the navigate table.
(In reply to comment #10) > Created attachment 190571 [details] > "shash" comes over the table > > Nayna, try to catch the sash and move it side to side. The sash moves over the > navigate table. Gosia, that is bug 338764. I was seeing this all the time last week, but had trouble reproducing today. Could you add steps to that bug?
