Re: Long Menus issue (Was: Re:NeXTGtk ?)



On Mon, 1 Jun 1998, Zack Williams wrote:

> This came up in a different discussion, but I think it needs to be paid more 
> attention to. The problem is: What do we do when a menu is to long to fit on 
> screen (like a font menu in some GUI's, Gimp plugins). We want to be able
> to see all of the choices in the menu, but most current solutions don't
> work too well. I know that currently font selection does not occur in a 
> menu, but we must deal with cases where applications, especailly extensible
> ones, need to be able to handle such cases gracefully, without any extra 
> code. These are the most common ideas:

[lots of ideas deleted]

Two words: Toolbar Combobox.  (ok, I sorta cheated - it's really four 
words:-)

Of course, the dialog is also good, but for programs like word 
processors, where you need quick access to font changes, there's nothing 
better.  Best of all, it doesn't need any gtk+ changes.

IMHO, this also works better for history lists and other things where the 
number of items can grow without bound and you don't want to interpose a 
dialog.  I do like the "least recently used" lists on the menu, but only 
if they're bounded (most I've seen are bounded to four).

All IMHO, OC.  YMMV.  IANAL.  FITB MA (fill-in-the-blank missing-acronyms).



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]