Re: [gtk-list] Widget user interface comments



On Fri, 11 Sep 1998, Michael Babcock wrote:
[snipped some stuff]
> though I do worry a little that Rasterman and themes et al are more 
> concerned with "look" than with "feel".
Agreed.  Clicking on a button, then moving the mouse out of the button's
rect should not activate the button (or maybe GTK apps don't have this
problem and I've been smoking too much crack).

> Although you can doubleclick to select a word, you can't
> doubleclick-drag to select multiple words a word at a time. 
I don't think that's a good idea.  Drag-N-Drop will be activated the same
way.  I think (and maybe this is what you're trying to say) that the user
should doubleclick, but *hold* the button down on the second click and
then drag.  That's how it's done in MacOS; it feels right and it doesn't
conflict w/DnD.

> Clicking the down arrow or pagedown area  of a scrollbar should wait a
> bit after the first scroll before continuously moving while the mouse
> button is held down. It is too hard to scroll just one line.
Yuck.  I hate forced delays; they feel like wWindoze.  Maybe we could
overload one of the other buttons so it doesn't automatically scroll like
crazy.

> I think scrollbars should by default be wider. I know we're following
> Motif, but I think new users find them too small.

I disagree.  We should leave them the same width, but offer a "biggie"
theme.  Unnecessarily large window parts waste the valuable space on
smaller resolutions.

> This one might be controversial. While I do like the menu items
> highlighting when the mouse moves over them, I don't think submenus
> should automatically pop up without a click (obviously, if you drag
> the mouse to use menus, they will have to). The problem is that its
> too hard to "thread the needle" by moving the mouse pointer horizontally
> to the right to the submenu without moving it up or down to make the
> menu disappear. Another solution (Apple approach) is to have a little
> delay before the menu disappears after you move off the item, although
> I worry about the interface feeling sluggish.
What you're saying doesn't make sense.  If you're having trouble
"threading the needle" without the button clicked, don't you think you'll
have even more trouble navigating with the mouse button pressed?  Auto
pop-up is one of the things I really like about GTK apps.  It makes an
apps interface feel snappy and responsive, unlike MacOS or Windoze.

> When a menu is displayed, clicking on the title again should make it
> disappear.
Yes, Yes, Yes! As a former Mac user, this is one of the most infuriating
GTK UI quirks for me.

> Keyboard navigation seems weird. Sometimes moving down with the down
> arrow key doesn't scroll you down.
Agreed.  I would also like it if the Keypad enter button was mapped to the
default button (eg "Okay or Cancel") in Modal dialogs (anyone ever use the
script editor for HyperTalk?  This feature made it really slick).  Esc
should be mapped to Cancel if it exists.  

> I have seen new users confused about which visual state means on
> versus off. We all are familiar with the Motif look, but I think
> perhaps by default, when check and radio buttons are "in" they should
> draw a mark in black inside to make it obvious.
Again, I agree with you.  Radio buttons are a bit ambiguous right now.

> Personally I think the Mac look, with the left or down triangle and no
> dotted lines looks much cleaner than the windows look implemented in
> Gtk, with the + and - and the lines connecting everything. I think you
I also like the mac look more, but what really impresses me is the
keyboard commands on the mac side.  You can select a bunch of different
tree items, the press Command-left arrow and all of those tree items will
expand...  Very nice

> Comments?
I agree with most of your points, but I don't think we should be putting
delays in the menus or the scroll boxes.  It seems more appropriate to
check for a keyboard modifier or alternate button (eg middle or right
click) before changing that sort of behavior.  That would keep the
interface consistent (read: non-insulting), and still allow the
functionality you're describing to be used.

/*
Paul Duncan	p_duncan@efn.org	Indifference will be the downfall 
http://www.efn.org/~p_duncan		of humanity, but who cares? - fortune

"in short, all known bugs should be     "I'm to blame; I wonder just who
 fixed, but hey, what else is new?"     made the rules up for this game."
  - Linus Torvalds			  - nine inch nails
*/




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]