Re: [patch] Scrolling menus

[Nils Barth <nils_barth post harvard edu>]

Hi -- this subject is of interest to me, though I haven't been
following this latest patch due to time constraints; I'll try to be
helpful/try it out shortly (next week maybe)?

Having not tried it, I have a thought or two:
(1) It's prolly a better idea to try to emulate Macintosh behaviour
than MS, given their comparitive records on UI design.

(2) We also need a way of dealing with overlong menubars;
(one suggestion is to wrap them onto several lines, a la MS -- this is
pretty bad in that you can't easily access menubar items covered by
menus, for instance!) -- I'd suggest doing this the Mac way, i.e., to
have a scrolling arrow at the edge of the menubar to scroll the
menubar, in a way completely analogous to the scrolling menus.
If this sounds good, then perhaps you (or I?) could hack your patch to
allow scrolling any menushell.

Thus spake Alexander Larsson:
> On 16 Oct 2000 otaylor redhat com wrote:
> 
> > Alexander Larsson <alla lysator liu se> writes:
> > 
> > Let me first note some problems with the behavior from testing:
> > 
> >  - I think it looks a little funny to have the menu items just cut
> >    off by the scroll arrows. 
> >   
> >    Perhaps there should be some separator or relief between the two-
> >    e.g., make the scroll arrows raised buttons.
> 
> Windows does show a relief when the arrow is prelighted. I'll experiment
> some to see what looks good.
>  
> >  - If you pop up the menu with a single click, then you have to
> >    keep on clicking on the button for each scroll incroment.
> >    If you get into a rut of doing this, then when the scroll
> >    arrow disappears, you will select the first menu item.
> > 
> >    There should be an autorepeat here.
> Would it be better if the behaviour when opening with a single click was
> the same as when holding down the button (i.e. just mousing over the
> scroll arrow starts the scrolling). It seems that is what MS does.

hmmmm....Macintoshes actually scroll on mouseover, that is, no need to
click. In fact, as mentioned in a previous thread, they auto-scroll at
2 speeds: if you're just inside the arrow area, it slowly inches down
the list (about 2x/seconds), while if you're at least half way inside
the arrow area, it speeds through the list (about 20x/second).

I think this is somewhat better, as a menu is basically a transient
that you click on once, to select the item you want; so if the item is
off the visible area of the menu, you just `move off the edge' and it
scrolls.

> >    For torn off menus, when this happens, you untear the menu.
> >    I tend to think that the tear-off indicator probably shouldn't
> >    scroll, though implementing that is not easy. 
> > 
> >    (Note that in IE, for the Favorites menu, only the favorites
> >    scroll, and not the "Edit", etc, options, so the general facilitiy
> >    to define an unscrolling top section could be useful.)
> 
> Having a non-scrollable part of the menu seems like a good idea. There has
> to be some sort of public API to define what parts should scroll though.
> I'll look into it. Scrolling is a GtkMenu only thing, so maybe something
> like:
> 
>  gtk_menu_append_nonscrollable (GtkMenu *menu, GtkMenuItem *item)

Hmmm...I'd like to see other examples of where this would be useful;
this example could be misleading, for instance maybe it would be
better if there were two menus: one for adding/editing/managing
bookmarks, the other one holding the bookmarks.
That said, some other uses:
* recently opened files in an office program (word processor,
  spreadsheet)
* If we have scrolling menubars, we may want to have Help always show
  up on the right, so the menubar would look like:
File Edit Table Bookmarks --> Help
...where --> is a scrolling arrow for accessing further menus.
* Keeping major menu items always visible (File->New, File->Open,
  File->Save, say....)

Note also that the `recently opened files' and `bookmarks' are
analogous, and have a common problem: they are menuitems that reflect
DATA, not commands.
To elaborate: in a document-centric view of the world, the menubar
should reflect only the commands you can perform on the current
document (save it, print it, add a table, etc.). Accessing bookmarks
and recently used files is really more of a file navigator task than
an application task.

Also, if you're navigating a menu, you're basically going in to select
-one- item, so if you scroll down to the bookmark area, you don't want
to add or edit bookmarks, you want to access one of them, so the
non-scrolling menuitems just waste space -- you've passed them by, so
you don't want them.

That said, if you tear-off a menu, you might want the major items
always visible and the minor items to scroll; however, this mostly
serves to show that torn-off menus are UI-wise very different from
regular menus: they are persistent objects rather than transient ones,
and do best with a different interface (for example, a scrollbar for
scrolling).

> >  - The fact that when you tear off a menu, it tears off at the
> >    size that it was when you tore it off and it stays that way
> >    is a little odd. I almost think that if you have a scrolling
> >    menu and you tear it off, you should get a scrollbar.
> 
> All the tear off code makes the code really hacky and hard to grasp, and
> it gets hackier as the difference between the normal and tear-off
> behaviour increases. Having a scrollbar in the popup is a good idea, I'll
> see if I can make it so.

Hmmm....would it be possible to separate tear-off menus into a
separate class?
That is, make MenuTearoff another derivative of MenuShell?
Currently we have:
GtkMenuShell
  GtkMenu
  GtkMenuBar
given the hackishness described above, and my comments that tear-off
menus really require a different interface than transient GtkMenus, it
seems that it would be best to have:
GtkMenuShell
  GtkMenu
  GtkMenuTearoff
  GtkMenuBar
or
GtkMenuShell
  GtkMenu
    GtkMenuTearoff
  GtkMenuBar

This would likely require some codeoverlap between GtkMenu and
GtkMenuTearoff, but it would reduce hackishness and make it easier to
get the UI right for each case.

> >  - Something weird happens with option menus - when an option
> >    menu is popped up with scroll arrows, the current item is
> >    not selected on popup as it is in other cases, so you have
> >    to move off it and then move back.
> > 
> >    Also, with option menus, in my opinion, if you pop it up
> >    with only one line showing, then as you scroll, more lines
> >    should become visible. That is, the menu should move onscreen
> >    as you scroll, not just stay small and scroll.
> > 
> >    Finally, with option menus, the limiting case where the menu is
> >    right on the edge of the screen works really badly - you can get
> >    scroll arrows and nothing else. (In fact, I was able to get a
> >    assertion failure in gtk_menu_handle_scrolling in this case) I'm
> >    not really sure what to do here - the suggestion in the previous
> >    paragraph will help some, since if you scroll a bit, more will be
> >    visible. If that is not sufficient, then perhaps we need to force
> >    one line of the menu to be always visible, even if that breaks
> >    it so that the current menu item isn't immediately selected.
> 
> I'll have to think some more about the whole size/positioning issue.

Let me suggest the way the Mac does it:
First, note that the Mac Human Interface Guidelines suggest that menu
sizes shouldn't change after they've been created, since this reduces
the perception that they are an object; second, a person should be
able to access menus the same way no matter where they appear on a
screen, so that they can always, for instance, move the mouse onto the
menu and then down 2 cm to select an item, say.

Thus, what Macs do with over-long menus is:
(1) Always put the first menu item at the point where the menu pops up
(2) If the menu is too long, er...a picture would help:

pre click:
+-------+
| menu V|
+-------+

post click:
       +--------+
       |        |
       |        |
       |        |
       |        |
       |        |
+------|        |
| menu | item 1 |
+------| item 2 |
       | item 3 |
       |   V    |
       +--------+

after scrolling a bit:
       +--------+
       |   A    |
       | item 3 |
       | item 4 |
       | item 5 |
       | item 6 |
+------| item 7 |
| menu | item 8 |
+------| item 9 |
       | item X |
       |   V    |
       +--------+

Basically, the menu is drawn big enough to hold all the menu items
once scrolled up, and to do this it leaves blank space in the top of
the menu.

The alternatives to this, as I see it, are all inferior:
(1) just leave a small scrolling box
 this makes navigation harder because you have a small box
(2) make the menu grow upwards as you scroll downwards
 this requires lots of window resizing, which causes distracting
 visual noise and is surprising to the user
(3) always draw a big menu that takes up the whole screen, and select
    the first item
 this kills the connection between the menu button and the menu
 itself, and makes the user have to search for the highlighted item
 and makes mouse navigation a royal pain.

Thus, I'd recommend The Mac Way on this one.

The mac people put a lot of work into making their menus work right;
I'd suggest trying out mac menus for a bit to get a feel for them; GTK
could do a lot worse than imitate them.

I'd also suggest looking at:
http://www.mackido.com/Interface/
particularly
http://www.mackido.com/Interface/menus.html
which gives some good ideas/thoughts about menus.

Thank you so much for working on this! This is a really important UI
element.

-- 
  -nils