When selecting color palettes which have less colors than can be displayed in the color list (e.g. gallery.soc), the scrollbar disappears and results in color boxes being wider than when in they normally are in other palettes. So it would be useful to always have the scrollbar visible and dimmed when the list isnt long enough.
I think making the scrollbar always visible is the wrong way to fix the widget stretching you describe (“… color boxes being wider…”), because: 1) when the scrollbar is thin (e.g., in elementary), the boxes are stretched anyway 2) it just doesn’t make sense to have inactive widgets in UI. Let me quote bug 86050 comment 1: “… it would be very sophisticated if the scrollbar would not be there at the beginning if there is nothing to scroll…” So, if you don’t want the boxes to be wider than normal, then the boxes *themselves* should be fixed, instead of relying in having an independent element hiding the bug as a side effect!
(In reply to Adolfo Jayme from comment #1) > 1) when the scrollbar is thin (e.g., in elementary), the boxes are stretched > anyway In most themes the scrollbar is not thin (e.g. windows 7 aero, ubuntu unity, mac os x aqua), so thin scrollbars are the exception. > 2) it just doesn’t make sense to have inactive widgets in UI. Let me quote > bug 86050 comment 1: “… it would be very sophisticated if the scrollbar > would not be there at the beginning if there is nothing to scroll…” Yes that makes sense in a text field where the contents of the field are modified by the user, but this scenario is different. > So, if you don’t want the boxes to be wider than normal, then the boxes > *themselves* should be fixed, instead of relying in having an independent > element hiding the bug as a side effect! The wider boxes is an effect of having or not having the scrollbars, so always having the scrollbars is the correct fix, IMHO.
Sure, but isn't the issue that we are allowing the color swatches of a pallet to resize? I assume they are being calculated as percentage of the available width within the containing UI frame. tango.soc are rectangular, standard.soc are square. As the color picker is non user resizable, couldn't the color swatches be set fixed width? With fixed swatch sizes we could leave the vertical scroll present but dimmed inactive for smaller pallets. Or if having an inactive scroll bar visible is of concern--with fixed size swatches, an alternative might be to expand the frame to show the scroll bar when needed (at width of the respective DE widget)--frame would resize, not the color swatches. Selecting a large pallet with more swatches than fit would resize the frame, those with less would shrink it. Scrollbar retained on right, layout would have to be pinned to left edge and expand right. When torn away from menubar, pin position top left and again expand frame right for pallets needing scrollbar to limit visual shift of the pallet swatches. Another aspect of this is the Recent color swatches, they do not resize now since the pallet scrollbar when present above does not extend into that part of the frame. Unfortunately, in a visual glitch we now don't seem to provide quite enough vertical height as padding in the widget so the swatches are crowded.
(In reply to V Stuart Foote from comment #3) > Sure, but isn't the issue that we are allowing the color swatches of a > pallet to resize? I assume they are being calculated as percentage of the > available width within the containing UI frame. tango.soc are rectangular, > standard.soc are square. I believe that the colors being resizable is part of the problem, but that problem is likely needed to be addressed when we want to deal with color palettes that dont fit well in the 12 entries per row that we force color palettes to be put in. > As the color picker is non user resizable, couldn't the color swatches be > set fixed width? I think if we fixed it in tango.soc (as an example) it would put 13 entries per row rather than 12, if the scrollbar is invisible. > With fixed swatch sizes we could leave the vertical scroll present but > dimmed inactive for smaller pallets. Yes this was what i was suggesting, that it be dimmed when it is not needed.
(In reply to Jay Philips from comment #2) > > 2) it just doesn’t make sense to have inactive widgets in UI. Let me quote > > bug 86050 comment 1: “… it would be very sophisticated if the scrollbar > > would not be there at the beginning if there is nothing to scroll…” > > Yes that makes sense in a text field where the contents of the field are > modified by the user, but this scenario is different. No. It is not a different scenario at all. It is the very same thing, an UI managing content overflow. A scrollbar is needed when content overflows its container, when it doesn’t, then don’t add a scrollbar. > The wider boxes is an effect of having or not having the scrollbars, so > always having the scrollbars is the correct fix, IMHO. You did not seem to understand my point, at all. Why should you “fix” a UI element by introducing another bug (i.e., forcing a scrollbar to appear when it’s not needed)?????????? It’s simply beyond me, and I don’t want anybody to do that. It’s simply the wrong way to do it. You have an issue with a box, you fix the box itself.
I'll bring up the issue at next week's design meeting so it can be discussed.
There’s nothing to discuss in the call. What you are proposing to do is a WORKAROUND to CONCEAL (not fix) a bug which has nothing to do with scrollbars. And by unnecessarily forcing these controls to be always visible, you’re breaking the oldest, most influential standards on how graphical user interfaces are meant to work. Have you ever read IBM’s Common User Access, for example?
(In reply to Adolfo Jayme from comment #7) > There’s nothing to discuss in the call. Actually there is, the construction of the GUI now allows resizing of the elements, as in comment 3, we could correct that redraw with fixed size swatches and pinning the frame on left edge--allowing it to expand right when scroll bar opens. Or, we could go the route Jay suggested of a fixed but inactive scrollbar, that would not be my choice.