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

On Mon, 1 Jun 1998, Frederick I Gleef wrote:

> > 	So!  Lets work on finding working solutions for times when the
> > menu is bigger than the screen.  We can put a note in the style guide
> > about menu size if it makes people happier.  But this is a problem we need
> > to find a solution for.

> The more detailed the style guide is, the happier I would be.

	I think everyone can agree to that...  Now to just make everyone
agree to what it should say.  ;^)  

> I can't seem to find the exact size of the Pilot screen, but I know it's
> not big, and I'm pretty sure it is taller than it is wide.  Therefore to
> support Pilot screens, the extra column solution won't work at all.  The
> dot resolution isn't very good, so we wouldn't have much flexibility with
> fonts.  I am not sure if the Linux/Pilot developers are setting it up with
> a virtual desktop larger than the screen (IMHO the best solution), but we
> cannot assume that we will always have this luxury.

	This is actually a very interesting problem...  And it needs more
discussion.  Can a theme be created for screens which have tiny, irregular
sizes?  However, I'm more interested in the other issue at the moment:
What should a gnome application do when a menu is too big for the screen?

	I'm tired of the debates about menu size -- my point is that a
screen displaying Gnome applications can be quite small...  I used the
Pilot example, but I've also seen X Windows running on a 320x200 screen.
(At that resolution, most things don't fit.)  

The suggestions so far are:  

	* Make a "more..." menu item at the end.  This is used by Netscape
4.0 on UNIX.  It is rather poorly implimented.  My favorite example of all
time, New Menus For Windows (3.1) sometimes used this method, but stacked
the menus better.  It was actually fairly clear.  

	Note that the "more..." menu item does NOT have to open a
sub-menu.  It can open a dialog box with the rest of the menu items.

	* Use the "/\" and "\/" menu items to scroll the menu.  This is
used by the Mac.  

	* Use a drop down list for menus.  This puts a scroll bar on the
side of menus which are too long.  This may be my favorite solution.  I
might like it more if the scroll bar looked like this:
                       /\ So you can scroll up/down easily.  I also
                       \/ think this scroll bar should be VERY thin
                       .. and should be auto scrolling.  This means 
                       [] that if the user drags the mouse to the 
                       .. top of the screen, the menu scrolls up.
                       .. (Works with the bottom too.  This would
                       /\ only be if the user has not released the
                       \/ mouse button.)

	* Use a dialog box instead.  This would make the menu create a
dialog box when clicked.  I HATE this idea.  Too much mouse manipulation.

	* Create menus which are multiple columns.  This isn't a bad idea
either.  New Menus for Windows uses this at times.  Photoshop uses it too. 
I guess the Start button on Windows95 uses this as well.  But it isn't
something which should be created at run time. The menu needs to be
organized in this column format by the programmer.  This lets developers
layout the menu correctly.

	Well, I guess that's it.  The menu with a scrollbar is my
favorite.  Comments?

> PS: I love your .signature file. :-)



------------------------------------ |\      _,,,--,,_  ,) ----------
Benjamin Kahn                        /,`.-'`'   -,  ;-;;'
(212) 924 - 2220                    |,4-  ) )-,_ ) /\ --------------- '---''(_/--' (_/-' ---------------
 If you love something, write it in C; if it compiles, it is yours; 
                     if it doesn't, it never was. 

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