[ENH] Update of addHorizontalScrollbars changeset for 3.7 ([er][et] [approved])

Doug Way dway at mailcan.com
Thu Mar 25 00:40:38 UTC 2004


(Steven's original post didn't make it to squeak-dev... I'll reply here.)


Steven Swerling wrote:

> Hi Doug,
>
>> There are some remaining issues:
>>
>> - I tried turning off inboard scrollbars (I know some people like the 
>> flop outs), and the flop-out horizontal scrollbar is not reachable 
>> and sometimes overdrawn by the optional button panes.  A quickie 
>> temporary fix would be to simply not show the horizontal scrollbar in 
>> flop-out mode.
>
>
> This is an easy bug to fix. It's just caused by the order in which 
> submorphs get added when the window is initialized. [**Explanation, 
> which you can skip: Since the class/instance switches are added after 
> the scrollpane when the browser is initialized, and since they both 
> occupy the same area on the screen, the class/inst switches drawn over 
> the hScrollbar, as they should be**]. I can just fix these piecemeal 
> as they are reported. I now have a fix for browsers, which is the only 
> case I know of. Will post it as soon as I get feedback and can take 
> action on the item below.
>
>> - The hiddenScrollBars preference has no effect.  Er, um, it could be 
>> a 3-way preference?  
>
>
> That's by design. Before, the hidden scrollbars pref would only show 
> the scrollbars "if the pane's contents are too large to fit inside the 
> pane", in other words, only if needed. But that's the default behavior 
> with the hScrollbar changeset. My guess is that it wasn't on by 
> default before simply because it was a bit buggy before. Again, it 
> would be easy enough to make it however you want it, and I think it 
> should be your call -- you're the guide, requesting guidance. What'll 
> it be -- a pref for "alwaysShowScrollBars"? Or, a pref for 
> "hiddenScrollbars" (only show them as needed)? Or, 2 prefs, 
> "alwaysShowVScrollbar" and "alwaysShowHScrollbar" (seems a bit much, 
> but makes sense for squeak, since the vscrollbar provides a mouse 
> interface to the context menu)?


I think we do probably need the 2 prefs, even if it seems like overkill 
at first glance.  Now that I think about it, there are a couple of 
reasons why someone might want the vertical scrollbar to always be 
showing, but the horizontal scrollbar to be optional:

1. So that the menu button is always showing (for PDA's/1-button mice), 
but you don't always have the annoying horizontal scrollbar taking up 
space when it's not needed.  The horizontal scrollbar seems especially 
inappropriate when you're looking at a PluggableTextMorph, which is 
always wrapping text anyway.

2. When you have the vertical scrollbar set as optional in a 
PluggableTextMorph, it can seem a tiny bit weird that the vertical 
scrollbar can suddenly appear while you're entering text, and it 
actually squeezes your text at that moment so that it wraps 
differently.  I don't personally mind this, but I could see that some 
people might not like it.  (Most UI's don't do this... they simply 
always have space allocated for the vertical scrollbar.)

So anyway, with the two prefs, someone can choose to always show both 
scrollbars, or optionally show both, or always show vertical and 
optionally show horizontal (which should be the default IMHO), or vice 
versa (though I can't imagine anyone wanting to do that :-) ).

- Doug





More information about the Squeak-dev mailing list