scrolling menus

[steve@cegelecproj.co.uk (Steve_Kilbane)]

> sam on the blit had scrolling menus because someone
> else implemented them in the library that sam linked
> with.  i found them unusably fussy to navigate so when
> sam moved off the blit scrolling menus were left
> behind.  a good implementation might save the idea
> but that is harder than most realize.

they are awkward, this is true. but they do work.

> the simpler solution, the one we apply here, is to keep
> the list of files manageable.  this means the menu works
> equally well for all files all the time.

hmm. not entirely a suitable solution. "sam *.c" is a common
invocation, and it's irritating to have to quit again, just
because the menu's too large.

> of course, this is a matter of taste.  you have the
> source.

indeed. one approach i tried was to have a "more" option on
menu three. the number of files listed in menu three were
limited by the size of the main window, and the "more" option
cycled the files that were available. It worked, but it was
even more sloppy than the scrolling menu, which is what i
use now.

out of curiosity, has anyone tried menus that required a double
click? First click pulls the menu up, second selects an option
or dismisses the menu (if outside of the menu). if the menu had
a scrollbar, it would function like a normal window's scrollbar.
of course, this goes against the "minimum action from the user"
principles in rob GUIs, but it's just a thought...

steve