[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
|