Re: Global menubar (was Re: #4 on ToDo list: make the top panel prettier)

On Mon, 2009-01-26 at 18:55 +0000, Matthew Paul Thomas wrote:
> [resending my original reply]
> On Jan 19, 2009, at 8:37 PM, Owen Taylor wrote:
> >
> > On Mon, 2009-01-19 at 20:34 +0100, Jonas Jørgensen wrote:
> >>
> >> 2009/1/19 Owen Taylor <otaylor redhat com>:
> > ...
> >>> I have some opinion that the global menu bar is pretty tied to
> >>> the application-centric model of the Macintosh .. it's not entirely
> >>> clear to me that you can go to the global menu bar without adopting 
> > that model wholesale. Which would be a pretty major change to the 
> >>> way the desktop works.
> >>
> >> I'm curious as to why you have that opinion, and I'd love to hear an
> >> explanation of it -- because I strongly prefer the
> >> menu-bar-in-top-panel approach, and I strongly dislike the
> >> application-centricism of Mac OS :-)
> >
> > Well, on the Macintosh, to really use the computer effectively, you do
> > have to understand the concept of an application being "current". This
> > is exposed, among other things by:
> >
> >  - All windows of an application come to the front at one
> (This happens in fewer cases in Mac OS X than in Mac OS 9 and earlier.)
> >  - The ability to "hide other windows" to hide windows not from the
> >    application
> >  - The menubar staying there when you close the last window
> >  - The dock icons activating an application
> >
> > The global menu is part of the "bundle" of concepts.
> I don't follow that logic, and the Amiga is a counterexample to your
> bundle theory. The Amiga had a global menu bar, but its applications
> had none of the other attributes you list (except for applications that
> had a "screen" of their own, and those became fewer as the baseline
> graphics improved).

I'm in a corner here... if I bad-mouth the Amiga, I risk getting on the
bad side of both you _and_ Calum.. :-) Seriously, I don't have anything
bad to say about the Amiga, but we're 20 years on, as visionary as it

At the most basic level my logic is pretty simple and I think
uncontroversial - that different parts of design do interact. That the
application design which is optimum when the menu bar is in the window
is not necessarily optimum when the menubar is moved globally.

My closest personal experience here is with Reinteract. The screenshot
at the bottom of:

shows the basic design used with GNOME and Windows. You have a window
that represents a "notebook" with a side-pane listing available 
worksheets and tabs for the open worksheets.

A couple of months ago I ported Reinteract to OS X. The initial version
takes that design and moves the menu bar globally.... pretty much like
what we are discussing doing here. That design feels very strange on the
Mac, even with a lot of care taken to do the menubar "right" (organize
items according to Mac conventions, sensitize/desensitize) because the
single window with tabs is all about grouping the "application"
together. Once you split the menubar off, then that grouping no longer
makes much sense, and an X-code style design where worksheet windows
float free would be much more natural.

Now, it may be that the dissonance of this approach isn't because of the
menubar, but the other aspects of the Macintosh's application-centric
design, and it would work better in GNOME. I'm not sure about that. But
I certainly think that the location of the menubar does have an effect
on how you design your application.


> > ...
> > But large monitors have become cheap and common (22" could be said to
> > be the standard size at this point),
> It could be said, but only by someone unaware that notebooks are now
> outselling desktop computers worldwide. ;-)
> <> So if
> there's a "standard size", it's about 14". (And 9" and 10" are
> surprisingly popular.)

Perhaps the better conclusion here is that diversity is increasing. A
17" laptop (especially considering viewing distance) is a lot more like
a 22" monitor than a 10" netbook. And using a laptop isn't exclusive
with using one or more large monitors when you are at your desk.

The diversity both of physical configurations and of work habits is
something we can't really get away from in designing the next generation
of GNOME. To the extent that we can design ways of working with the
computer that naturally scale and adapt, then we aren't just covering a
broader range of markets, we are also making things better for the
person who takes their small-form-factor laptop and plugs a big monitor
into it when they sit down at their desk.

[... skipping a bunch of stuff I don't have a specific reply to ...]

> >                 What happens with windows without a menu bar? (From an
> > app with other windows? As a standalone app?)
> "File" > "Close" would still be applicable, and so would the standard
> "Edit" menu items for any window that contained a text field.
> Cocoa is designed such that child windows don't need to do anything
> special to ensure that all the relevant menu items stay available, while
> all the irrelevant ones become unavailable automatically.
> <> If a global menu bar was
> introduced, adding this kind of system into GTK would make it easier to
> ensure that (for example) the Help menu remains accessible while you're
> using a dialog.

This gets back to my point that the global menu bar interacts with
application design.

I don't want to come across here as anti-global-menu here. There
certainly are advantages to the approach, and I think it's great that
people are doing experiments with that for GNOME and the GNOME shell. 

But we should be clear between:

 - What we can do as a pure window-manager/panel replacement

 - Redesigns of the GNOME desktop with significant application changes
   (which of course also extend to non-GNOME apps)

- Owen

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