Re: NeXTGtk ?

[Soren Harward <soren shell cinternet net>]

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....

-------------------------------------------------
                  Soren Harward                  
Assistant Sysadmin/Tech Support - Cinternet, Inc.
   Voice: 891-1228         soren@cinternet.net   
        http://www.cinternet.net/~soren/

Windows 95/98 DOES come with a tool that lets you
rebuild a corrupted Registry.  It's called FDISK.
-------------------------------------------------

On Sat, 30 May 1998, Gleef wrote:

> 
> I hate scrolling menus.  I hate menus with 'More' at the end.  There are
> many things that are annoying about them in general (takes longer to do
> what you want, etc), but there is one FATAL flaw that keeps either of them
> from being acceptable in a well-designed GUI, which GNOME aspires to have.
> 
> In both cases, if what you are looking for cannot be displayed on the
> first batch of menu items, the scrolldown arrow or the "More" tag will be
> found on the bottom.  There is no other place that makes sense to put
> them, anything else will be even more confusing.  Many applications and
> window manager features think that they are so important that they must be
> always on top, I'll use a taskbar in this example, but the problem is by
> no means limited to taskbars.  Now, since this taskbar knows that people
> will be annoyed if it is covering windows, it generally installs itself
> along the edge of the screen, typically along the bottom.  When the menu
> gets displayed, the taskbar is insisting that it must be on top, so the
> menu is displayed on a lower level.  The taskbar (or other window) is now
> COVERING the scrolldown arrow or "More" tag.  You now cannot use the other
> part of the menu without going through gyrations.
> 
> The solution cannot be "don't let the taskbar do that".  It may not be a
> taskbar, it may be the new statusbar feature from the latest closed source
> version of StarOffice 12, or whatever.  GNOME cannot assume that anything
> below the bottom border of the application window is visible, and both
> versions of 'long menu' solutions typically expand to fill the available
> space, regardless of whether or not it is visible, because there really is
> no way to check reliably.
> 
> The right solution is "don't make long menus".  A menu should have a
> static length.  Individual items within a menu may change dynamically,
> (eg, the 'last four documents editied' items in the File menus of the
> Microsoft Office applications).  However, if there is the opportunity
> for a list of items to grow boundlessly, a menu is the wrong way of going
> about it.  Use a combo list or some other way of controlling how the list
> is accessed.
> 
> I personally would like to see a item in the GNOME style guide that no
> menus should be taller than 400 pixels or the minimum window height
> (whichever is taller) using the default GNOME font.  This will allow for
> people running on 640x480 screens with stuff it to have minimal risk of
> problems along these lines.
> 
> -Gleef
> 
> 
> -- 
>          To unsubscribe: mail gnome-list-request@gnome.org with 
>                        "unsubscribe" as the Subject.
>