Re: [gtk-list] Re: Widget user interface comments

[Kenneth Albanowski <kjahds kjahds com>]

On Fri, 11 Sep 1998, Paul Duncan wrote:

> 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).

Oh, that reminds me: something most GUI sets miss (_somewhere_) is that
any action that isn't immediate, should be cancelable. I.e., a drag, a
resize, a click, whatever -- if you have to release the mouse button to
finish it off, then you should also be able to cancel it via some
mechanism -- usually the Escape key. When you hit Escape, the action
should cancel, everything should visibly jump back to its original state,
and releasing the mouse button will have no effect.

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

Historically, triple-click has selected lines and/or sentences, and
quadruple-click _has_ been known to select even a larger chunk. But this
starts to get silly (especially as their are folks who can't grasp a
double-click.)

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

The problem is that with the auto-popup design, if two submenu items
are next to each other vertically, you must keep the mouse pointer out of
all but the one you want, thus "theading the needle", horizontally. With
manual pop-up, the menu would not disappear if you move the cursor over
another submenu item, thus no restrictions on where you can move the
mouse, only restrictions on where you can click.

Note, however, that this whole issue isn't restricted to submenus. Main
menus have exactly the same auto-popup effect.


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

!! Please read carefully what Michael was saying about scroll bars: the
delay he is describing is absolutely standard, and is essentially required
because of human reaction times. (As it happens, I don't mind the current
behaviour, but my reactions might be faster then Michael's.) A (very
slight) initial pause is very helpful in getting control of repeating
actions, without slowing them down unnecessarily. (Just about all
keyboards have such a delay, for example.)

Note that there's one additional "feature" used by Windows (and perhaps
the MacOS), the "wiggling speed control". Namely, if you are scrolling
down in a text widget or list widget by selecting text, and moving past
the widget border, you can scroll/select faster by wiggling the mouse -- I
rather suspect that this is/was an accidental effect of timer & mouse
event handling, but nonetheless it was a useful way of speeding up
selection scrolling. (Again, the mere fact that selection scrolling is
useful points out to weaknesses in scroll bars.) Yet another approach,
this one intentional, was to use the horizontal position of the mouse
within the widget (assuming that one was selection scrolling vertically) 
to choose how fast the widget scrolled. I don't remember what GUI used
this (I have a nagging feeling it might have been SmallTalk/V.) 

-- 
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)