Re: Conceptual models (was: Re: Detachable menubar idea)

On Mon, 4 May 1998 wrote:
> ->  If there's a single application that can have multiple windows (like,
> ->  say, the gnome-terminal) will there be a single detached menu for all
> ->  windows (not currently) or do new windows still have their own menu
> ->  bars (currently so)?  If we had a concept of application layers (a'la
> ->  Macintosh or NeXT) then detached menubars would have a more
> ->  identifyable identity and a single detached menubar for all an
> ->  application's windows would make sense... but not as it is.
> Hmmmmm. Call me a biggot and flame away but I'm goignt to poitn a big
> finder at the user who detaches 10 menus and forgets whihc ones are
> which and say "thats you're problem - you deteached them" It's like
> forgetting what "the button with the X does" on the titlebar. Sometimes
> we have to assume some competancy on the user becuase bending over
> backwards for even the most newbie user will more often than not make
> the iunterface a kludge, unisable and horrible for the power user or
> those who have learnt about it.. personally i'd liek the option of
> "hidng" the menu and turnign it into a "floating" menu liek gimps, or
> ee's (right mouse button anywhere in the app bring sup the main menus
> unless context dictates another menu for that area).

	I've thought about how to support detachable menus for a long
time.  I've also used them in a variety of platforms, and it CAN be very
difficult to find the menus you detached.  

	One solution is to hide menus which don't relate to the current
task. For example, you don't want to see Netscape menus when you are
working on EMACS.  This is a common solution -- when you focus on a
differet window or application, all the other menus disappear and the new
application's menu show up.  

	This is a great idea...  Unless you don't use click to focus.  (I
know I don't.)  Well...  Then it should work with auto-raise.  Unless you
don't use it...  In which case it should operate on a delay.  Of course,
the more savvy amoung us will notice a small problem with this solution...
It ties the window manager to Gnome!  So maybe a good kludge would just be
a slight delay once focus is gained.  (In this case I imagine sloppy focus
would have to be used...  Or we'd need application to application
communication to determine which application should have menus visible.
They should disappear on a delay as well.)

	As for dealing with multiple windows in the same application, like
with Gnome....  That's a harder problem.  While the same logic can apply,
mulitple windows which are performing the same conceptual task, like image
editing windows, which also have the same menus, should operate on ALL the
documents.  There should not have to be a seperately detached menu for
each window.  How to do this?  Well, netscape solves the problem.  I think
they choose the window which was last used.  It FEELs very intuitive


------------------------------------ |\      _,,,--,,_  ,) ----------
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]