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

On Mon, 1 Jun 1998, Ben 'The Con Man' Kahn wrote:
> On Mon, 1 Jun 1998, Gleef wrote:
> > I have seen many programs made very difficult to use by poor menu design.
> > The "solutions" above will give poor menu designers tools to make the
> > menus worse, while giving good designers no advantage.  I would rather not
> > see "Long Menu" solutions until someone poses a good "Long Menu" problem
> > that would not better be fixed by other means.
> 	Alright...  You didn't quite understand the problem.  X Windows is
> device independant.  Why is that significant?  Well...  I'll use an
> example:  VNC has just been ported to the pilot.  That means you can view
> and use XWindows products on that tiny little screen.  (See where I'm
> going here?)  NOT EVERYONE HAS *EVEN* a 640x480 screen!  Any application
> we create will have to recognize the hostile places it can be run in.

I think I understood the problem as presented, since the examples given
were along the lines of "xfontsel menus are taller than the screen" and
"what if we need a menu of the fifty states".  What you have here is a
different and valid problem that needs to be addressed.

> 	This discussion is NOT about how to handle a growing list of
> fonts....  That's easy to fix -- just look at the GOOD solutions of
> others.  (Look at WordPerfect...  They use a list of the most recently
> used fonts in a popup list box with other fonts listed in alphabetical
> order underneath.) 

Good, the last discussion seemed to be about that, I'd much rather talk
about something substantive.

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

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

Now, to business...

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.

If we do want to support PDA Screen-sized GNOME, we have a lot more to
consider than just the menus, although the menus have to be part of the
solution.  GTK puts a lot of whitespace into dialog boxes, this would not
work properly on a PDA Screen.  I'm pretty sure the stock Yes/No box that
many applications use is wider than a PDA screen.  We would also need a
reduced height panel, the current one would overwhelm a PDA screen.

On a desktop implimentation, we want the whitespace that GTK puts in, on a
PDA we would need to minimize whitespace while still keeping things
readable and looking close to the desktop version.  Therefore, we would  
want GNOME/GTK looking two different ways for different environments.
They should look close, the functions should be analagous and easy to
learn, but if we try to impose the current GTK look and feel as it stands
on a PDA, things will be too large.  If we try to impose PDA design on
GNOME as a whole, we won't make desktop users happy.

Now, I see two ways to get GTK to look two different ways.  First, and
easiest is to use themes.  I do not know if themes as currently envisioned
would be flexible enough to do things like change menu functionality,
dialog box layout, etc.

The other, more radical method would be for someone to write GTK+PDA and
GNOME+PDA. A set of libraries, binary compatible with GTK+ and GNOMEUI,
which would display widgets in a more PDA friendly manner.  The stock
buttons would be smaller, stock dialogs would be set up differently.
Dialogs might follow the PalmOS standard of being the full screen
width on the bottom of the screen.  With this, long menus could use
whatever technique seems to work best by the PDA developers, personally,
given the hardware restrictions, I would suspect scrolling menus would be
least objectionable.

This could work, if people are interested in putting the time and the
hardware into it.  The PalmPilot simulator I've seen screenshots of might
help this effort.  Just remember, to get something looking good on a PDA,
you need to address more than just the menu layout.


> ------------------------------------ |\      _,,,--,,_  ,) ----------
> 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. 
PS: I love your .signature file. :-)

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