Re: Scroll bars.
- From: raster redhat com
- To: gnome-themes-list gnome org
- cc: gnome-list gnome org
- Subject: Re: Scroll bars.
- Date: Mon, 26 Jan 1998 13:15:45 -0500 (EST)
On 26 Jan, Robert J. Slover shouted:
-> Shawn T. Amundson wrote:
-> >
-> > Scrollbars are generally on the right side so that it is easier to
-> > line up data visually. For example, say you have something like
-> >
-> > [label]
-> > [label]
-> >
-> > ^
-> > | Text
-> > |
-> > |
-> > V
-> >
-> > [Entry]
-> >
-> > This is worse than if it where on the right where the text could
-> > be visually lined up with the labels and entry. Lining text up
-> > on the right side makes no sense in a majority of cases.
-> >
-> > Also, if you put the scrollbars on the left and allow them to
-> > automatically come up when needed, the text widget (or list
-> > widget, etc.) would shift to the right, an extremely undesireable
-> > action.
-> >
-> > A general guideline in developing GUIs is that if you are going against
-> > the grain you are most likely wrong. This is not always the case
-> > obviously - but it is good to try and think of reasons why you should
-> > not change standards as well.
-> >
-> > -Shawn
->
->
-> I can't agree with this. Just looking at your E-mail in netscape here,
-> the text is all crowded against the left of the page. On my nice big
-> monitor the bloody scrollbar (way over on the right) is almost out of
-> the periphary of my vision. There's an acre of empty space between the
-> ragged right side of paragraphs and my scrollbar...this makes it more
-> difficult by far to align than if my scrollbar were on the left.
->
-> Wherever I have a choice, my scrollbars are NeXT style...on the left,
-> with both up and down buttons together...and a scroll thumb that
-> corresponds in size to the percentage of the region which is visible
-> on screen. That last feature addresses your concern about magically
-> appearing scrollbars...if 100% of the region is visible the thumb
-> takes 100% of the trough. The text does not have to shift if the
-> scroll trough always exists.
->
-> I think the right hand scrollbar is just a holdover from the
-> predominant right-handedness of people...it is an almost useless
-> extension of the pick-up-and-drag metaphor. In the real world if I
-> am right handed I am likely to grab my notebook by the right side and
-> pull it across the desk towards me. This is a physical optimization
-> and doesn't need to exist in a UI.
->
-> This becomes more obvious if you use your mouse on the left. I began
-> doing this a couple of years ago at the suggestion of a russian
-> friend...it leaves my right hand free for things like cursor keys and
-> the keypad. I tend to notice the navigational overhead in having the
-> scrollbars on the right a lot more now because I now 'park' my mouse
-> at the lower left corner whereas it used to be the right. I do a
-> little less navigation to menus now though.
->
-> Also...to respond a bit to Gary Vaughan's suggestion of a 'mark' that
-> appears in the scroll trough...great idea. I've never seen that done
-> but I can immediately appreciate the uses of it. I would think the
-> GUI interaction with this might be similar to 'guides' in something
-> like PageMaker...drag a mark from a well located at one end of the
-> scrollbar and plunk it down next to the position you want to mark.
-> Grab and drag it off into the ether to clear it...simple interaction.
And this is all the more reason for themes. Let the user configure his
apps how he/she/it likes them. users can select laft/right scrollbar,
top/bottom scrollbar, arrows, no arrows, etc. etc. etc. Then there is
no argument anymore. It's a user preference. Let's not get religious
about "I like next style" or "I like win95 style" or " I like mac style"
or "I like xaw style". In the end everyone likes something different.
That, in my humble opinion, is a really good reason to discuss and get
some theme framework desgined and documented, that gives a full scope
of options for the user to modify at their leisure, and thus will allow
the programmers to start work on this, instead of waiting for some
desgin to materialize. If this isn't done now, sometime in the future
we will have springup projects like gtk-next gtk-macos gtk-E etc., with
each having different bugs, incompatabilites etc. We need to have a
framework in place that allows easy expansion and modification by users
via a gui. Whole sets of gui configs can be packaged together in themes.
--
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
raster@rasterman.com /\___ /\ ___/||\___ ____/|/\___ raster@redhat.com
Carsten Haitzler | _ //__\\ __||_ __\\ ___|| _ / Red Hat Advanced
218/21 Conner Drive || // __ \\_ \ | | \ _/_|| / Development Labs
Chapel Hill NC 27514 USA ||\\\/ \//__/ |_| /___/||\\ 919 547 0012 ext 282
+1 (919) 929 9443, 801 4392 For pure Enlightenmenthttp://www.rasterman.com/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]