Re: NeXTGtk ?

[Gleef <gleef capital net>]

On Sun, 31 May 1998, Michael Hudson wrote:
>   On Sat, 30 May 1998, Soren Harward wrote:
>   > 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.
> I like this idea, though it might indeed be hard to implement.
The trouble is, that such lists should not be menus.  The primary purpose
of a menu is to allow the user to trigger program activities: "Open a
file", "Show me the help screen", "Compile my program".  Menus are not for
selecting things.  To select something, like "A state in the U.S.", or a
font, it should either be in a dialog box, or if such selection is the
main point of the program, it could be in a widget within the body of the
program.  It should not, however, be in a menu.


> It would only really work, IMHO, for attribute setting (like fonts) rather
> than actions such as choosing a plugin.
Both of these are better handled in a dialog box.  Plugins can work in a
carefully organized menu (eg. The Gimp), but I have a feeling that as the
number of plugins increase, even the Gimp team will start thinking about
other means and methods.


> Another idea would be to attach scrollbars to long menus, but that might
> end up being an interface monstrosity...
Again, you are getting the down arrow on the bottom of the screen, and
potentially covered by things.


> The only real problem is with lists that can grow without bound, like open
> documents or fonts. 
Fonts is a dialog.  Selecting between currently open documents is handled
under GNOME using gtk_notebook (Open gedit with a few files, look at the
tabs, all nicely arranged horizontally).


> 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.
Again, fonts is by a dialog box, as it should be.  The gnome-fonts dialog
is currently not in the GTK+ source, but I doubt people would complain if
they co-opted it.


> 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.
I too would not mind seeing tear-off persistent menus.  This could be a
Good Thing (tm), if it is handled properly.


> 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...
Try this (I know this works with the version of the GIMP distributed with
GNOME, I'm not positive about the one linked against GTK+ 1.0.3).  Go
through the menus to find the item you want, so it is highlighted, but the
mouse button is still held down.  Hit the accellerator key that you want
to associate the item with [Say 'W', or 'Ctrl-O' or whatever].  You should
see a hint appear next to the selected menu item.  You now can use this
key as a shortcut to that menu item.  Enjoy!


-Gleef