Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!uunet!stan!garya
From: garya@Solbourne.COM (Gary Aitken)
Newsgroups: comp.windows.x
Subject: Re: Toolkit for Open Look *and* OSF/Motif Look and Feel [why I don't believe]
Message-ID: <1991Feb27.001706.22673@Solbourne.COM>
Date: 27 Feb 91 00:17:06 GMT
Organization: Solbourne Computer, Inc.
Lines: 62

> Let me give a very simple demonstration of how a trivial
> difference between GUIs can result in major changes to the underlying
> application code.

> Today I got mail from someone who had just played with another mail system
> (with an OL GUI). She rather liked the way that some of the features worked.  
> In particular she liked the fact that it was easy to select Reply Sender or Reply
> Every (or a few other options).  This was done with an Abbreviated Menu
> which showed the current default.  The user can easily either just click and
> release to get the default, or hold down to change it.

> Now most GUI-independent interfaces implement this under Motif using an
> OptionMenu.  And in fact the two are very similar in concept.  There is however
> a major difference.  In Motif there is no way of instantly selecting the
> default option.  If you just click, it uses the click-wait-click model of
> menu selection.  The menu pops up and waits, and you then select the item you
> want (which will be under the cursor).  Alternatively you can use the
> press-drag-release model.  You press, wait for the menu to popup (again with
> the default under the cursor), and then release to select the item.

> Now "Reply" is a real common function in a mail program.  It's something the
> user does a lot, and they don't want to have to think about it.  Waiting
> for a menu to popup requires thought.  Not only that, it takes too much
> time on older/loaded machines.  As a result we've made Reply a button and
> we'll probably allow the user to specify elsewhere whether they want it to
> do a Reply Sender or a Reply Everyone.

> A generic API is *not* going to paper over things like this.

The generic API can certainly not decide to do this mapping for you.
However, one needs to back off a bit and analyze the real problem.  The real
problem is, the user wants a mouse accelerator to an underlying menu.  This
could be the underlying menu in the abbreviated/option menu, or the underlying
menu in a pulldown.  Motif provides great support in terms of keyboard
accelerators, but lousy (i.e. none) support for mouse accelerators in this
case.  It would
be fairly easy to do, simply extend the paradigm to allow some modifier of
mouse button 1 to fire the default, and some other modifier could be used to
set it.  It would also be easy to do by allowing a resource to be specified
which caused click to fire the cell rather than bring up the menu, allowing
the menu to come up only on a press.  Wake up, OSF!

What to do about it in an application given the current toolkits?

1.  If splitting out the extra button looks good and you have the screen space,
do it in both models.  The primary reason for using an abbreviated/option
menu is to conserve screen space/clutter.  If it looks good, expand it out.
You could claim that is "least common denominator", but it is actually
just good design in this case.

2.  If you have clutter / screen space problems, you don't have much choice if
you really are concerned with the clutter/space.
You have to use the abbreviated / option menu and live with its limitations in
each model.  Beat on OSF to provide a spec, even if they don't have time to
do it themselves, so other toolkit vendors can to it right.


-- 
Gary Aitken

Solbourne Computer Inc.    ARPA: garya@Solbourne.COM
Longmont, CO               UUCP: !{boulder,sun}!stan!garya