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 

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]