Re: NeXTGtk ?

[Michael Hudson <mwh21 cam ac uk>]

I like this idea, though it might indeed be hard to implement.
It would only really work, IMHO, for attribute setting (like fonts) rather
than actions such as choosing a plugin.
Another idea would be to attach scrollbars to long menus, but that might
end up being an interface monstrosity...
The only real problem is with lists that can grow without bound, like open
documents or fonts. 
The proposed solution could be implemented now for fonts, as the number of
fonts available does not change at run time, so a decision on presentation
could be made at startup, although GTK+ support would obviously make it
easier, and more widespread.
Whilst I'm rambling, it occurs to me that these scrolling lists that would
hypothetically pop up would have to be persistent, because otherwise it
would be _really_ annoying to have to go through a dialog box to flick
through different views or revisions of a document. Something akin to the
tear-off menus in WindowMaker would be great.
Now I'm really heading off at a tangent, but wouldn't it be great to have
a palatte in the Gimp where you can store you favourite scripts/plug-ins
and activate them with a simple double-click? I hate grubbing around in
three levels of menu to get to the plug-in I want...
I'll stop now.

Michael Hudson
Jesus College
Cambridge
mwh21@cam.ac.uk

On Sat, 30 May 1998, Soren Harward wrote:

> This is a bit of a radical idea, and maybe a little difficult to do, but
> here it goes:
> 
> Would it be possible to have GTK recognize when a single menu has run more
> than, say, a dozen lines?  If a menu did, then could it break off into a
> separate list box?  I am thinking of LONG single lists here, like all the 
> countries in the world, states in the U.S., or fonts on your system, i.e. 
> ones not usually split by a separator bar. For example, if you had a font
> list, rather than:
> 
> --------------
> |Fonts     >|-----------
> |           |Font1     |
> |           |Font2     |
> |           |Font3     |
> |etc ad nauseum...     |
> 
> You could have:
> --------------
> |Fonts ...   |
> 
> And then a separate box pop up.  This is a bit of a departure from
> previous UI conventions, but it might work.
> 
> What might work a little better is if in the code, it said "Okay, this
> is a dynamically generated list [like fonts or GIMP plugins] and it has
> the potential to run over 12 lines.  If it does, split it off into a box."
> Then, the programmer is left to honor and intelligence not to design menus
> bigger a doable size.  It doesn't prevent stupidity blatant, but then
> again, nothing in programming does....
>