Tear-off menus, version 2

[Michael Toomim <toomim ocf berkeley edu>]

An idea popped into my head about a menu widget behavior that I'd find
really useful, and I want to know if it would be feasible and/or
desirable to put it into GTK.  Would the developers here be able to give
me any feedback on it?

The idea is to let users select multiple items in a menu without having
to re-open it by control-clicking the menu-items.  A regular click on a
menu-item would select the item and close the menu, but a control-click
would select the item and leave the menu item so that the user could
select additional items, or the same item multiple times.

Here are a few scenarios:

1. The user wants to browse a bunch of configuration capplets from the
gnome foot menu in order to find a setting (or a set of settings).
Currently, the user has to click through all four of
foot->applications->desktop preferences->{config item} for each of the
capplets she wants to open (that's 16 hunt-and-clicks for 4 capplets).
With the control-click feature, she'd be able to click
foot->applications->desktop preferences once, and then be able to
control-click all the capplets she's interested in right there without
having to re-navigate the menu.  This would save 9 hunt-and-clicks, and
the last 4 clicks require a lot less hunting since the final menu would
remain open the entire time.

2. The user wants to click "undo" 7 consecutive times.  The "Edit" menu 
looks like this:

 ___________
| Edit      |
|-----------|
| Undo Move |  <- or "Undo Copy" or "Undo Edit", etc.
|           |
| ...       |
 -----------

Rather than click through the edit->undo sequence 7 times, with this
feature she would just click edit once, and then control-click undo 7
times without moving her mouse.

This has advantages even over using the keybinding for undo (C-z): the
user doesn't have to remember the keybinding; it is as fast or faster
(for some users) to control-click with the mouse than use the
keybinding; the user can be sure of the consequence of each of her
actions, because the menu says (in english) exactly what is being undone
with each click.  Personally, I avoid using keybindings in some
applications because of inconsistencies (does C-z undo, minimize the
window, or sleep the application in this context?  Or is it alt-z or
cmd-z?).

3. The user wants to change a bunch of boolean settings in the "View"
menu of her web browser.  (I'll use safari's View menu here because I
happen to be writing this on a mac.)  The safari View menu looks like this:

 _______________________
|  View                 |
|-----------------------|
|  Show                 |
|X   Address Bar        |
|X     Back / Forward   |
|      Home             |
|      Autofill         |
|      Text Size        |
|X     Stop/Reload      |
|      Add Bookmark     |
|X     Google Search    |
|      Bug              |
|                       |
|X   Bookmark Bar       |
|X   Status Bar         |
|                       |
|  Stop                 |
|  Reload Page          |
|  Make Text Bigger     |
|  Make Text Smaller    |
|                       |
|  View Source          |
|  Text Encoding ->     |
 -----------------------

It's currently very hard to change more than one of these at a time,
because the menu disappears after every click, causing the user to lose
her place visually, and then to have to move her mouse cursor back up to
"View" and then down again to the next menu-item of interest for each
setting she wishes to toggle.  This is especially a problem when the
user is trying to configure her toolbars on a large scale, since that
tends to be a task of experimentation and trial-and-error where she
would tend to select many different items multiple times, to try turning
them on and off.

4. The user wants to run a particular iTunes music visualization.
(Please pardon the Macintosh examples -- this happens to be the
particular task that inspired this post.)  Here's the iTunes
"Visualizer" menu at the beginning of the task:

 _______________________
|  Vizulizer            |
|-----------------------|
|  Turn Visualizer On   |
|                       |
|X Small                |
|  Medium               |
|  Large                |
|                       |
|  Full Screen          |
|                       |
|X iTunes Visualizer    |
|  Gforce               |
|                       |
 -----------------------

The user wants to run a full screen, large, visualization with Gforce.
Consequently, he needs to select four menu-items in the menu above.
This would be much easier to do if he could control-click to select each
menu-item without having to re-open the menu four times.


Tear-Off Menus:

The control-click feature would support much of the same functionality
as tear-off menus, which also allow the user to select multiple
menu-items without re-opening a menu.  However, I think the
control-click feature has the following theoretical advantages over
tear-off menus in the given scenarios:

A) It's far easier and less cumbersome (IMHO) to control-click multiple
menu-items than to click the tear-off menu-item, click the menu-items
you want from the menu, and then close the torn-off menu.

B) Tear-off menus are limited to saving only a single sub-menu.  For
instance, in scenario 1, if I navigated from the gnome foot to the
"internet" applications sub-menu and tore it off, I would be able to
invoke a set of internet applications, but it would NOT be easy to
navigate over to, say, the "office" applications menu.  However, this
would be very easy with the control-click feature, since the entire
chain of sub-menus would stay open on each control-click.

C) Torn-off menus are given window-manager window-borders and controls,
and the user is required to manage them like regular windows, including
having close the menu when done.  This would be an unnecessary burden in
the scenarios given above.

D) The control-click feature doesn't require a change to existing menu
widget like tear-off menus.  Tear-off menus have a "-------" entry added
to each menu.  I'm guessing (but I don't know) that tear-off menus were
disabled by default in gnome2 because of this extra clutter.  I think
the control-click feature wouldn't add any such clutter (or "crack") to
the interface, and can't think of a reason not to have it.

In the end, I think that tear-off menus serve a different purpose than
the proposed control-click feature.  Tear-off menus create persistent
custom user-interface controls, but aren't well-suited for solving the
problem of making many selections from a menu in a short period of time.


Other:

I only described how the feature would work if you open menu-items with
the "down-click and up-click on menu name, move mouse, down-click and
up-click on menu-item" technique instead of the "down-click on menu
name, move mouse, up-click on menu-item" technique.  In the latter case,
I propose that the feature would work by holding control during the
up-click.  That is, if you down-click on the menu name, move the mouse,
and hold down control while up-clicking on a menu-item, the item would
be selected and the menu would remain open.

If the user selects a menu-item that invokes a modal dialog box (such as
the "open file" dialog) the toolkit should probably close the menu even
if the user was holding down control.

Thoughts?


Thanks!

Michael