Always show menu bar for non-maximised windows

That was one of my proposal this morning during dx/desktop meeting. So I second that :)

Getting some design opinion on that can be nice.

 status opinion

I'll move this to Opinion for the moment, as it's a reasonable position
to take but it's not the designed experience. The current behaviour is
what is intended.

As alternative proposals, it may be useful to have some visual
indication that there is in fact a menu there, and we could ask the
visual designers to find a symbolic way to hint at that. I would only
approve that if it proved tasteful and clean, and did not add much
clutter (getting rid of the menu by default is aimed at reducing clutter).

I wonder if a solution here might:

  1. 90% blur/fade the menu so that it is faintly visible (per Quicklists/status)
  2. Slide the title off the top and fade up/de-blue the menu as the pointer approaches (rather than the current instant switch)

For (2) this transition could be in proportion to the pointer proximity and movement, perhaps building on the UI-interaction proposed for the hiding of the left-hand Launcher, being scaled proximity rather than time-based it would be clearer to the user what is happening and and that it is fully reversible by moving the pointer in the opposite direction. My thoughts would be that by the time the pointer has entered the menu area it remains 100% menu (just as at the moment) but that the transition is made on approach (in the half a panel-height below).

If the user is getting close they would see the title spring away and the menubar deblur and if they moved away again it would be back to the title of the currently focused window.

Paul, a more sophisticated transition than the current mouseover was the
plan, we just have implementation issues with X not easily being able to
tell people where the pointer is.

Mark

This is bugging me too. Even if it's not the default, a configuration option would be nice.

I totally agree with Robert's suggestion about the Global Menu. And by a possible configuration option it wouldn't have to look like this anymore (I guess the intention was to show which menu I'm working with, but it looks quite ugly (unaethetic) to use the space of the buttons to show the application's name).

I agree too, having the application menu in system panel for non-maximized application windows that are even often far far away from the top left corner where the application menu draws is really terrible, especially if you have to move the mouse cursor all the way using touchpad.

For maximized windows it is really useful as it saves some space by a painless way.

And as for the graphical side, the fade out effect in long window title that Johannes mentioned seems bad to me too, however, it doesn't appear in menus for maximized windows, thus in those for the non-maximized ones it wouldn't be problem if the menu was in its normal place - under the window header :-)

I'd suggest to always show the menu bar and fade in the title if the mouse curosor is above the shortened title, eg like this:

No mouse above the menu bar:
Chromi... File Edit View

Mouse above the title:
Chromium Webbrowser

If windows are not maximized, than the window title is shown on the window too and if it's maximized, then you simply hover above the title to fully reveal it.

Imho, the menus are more often used than it's necessary to show the title of a window - at least for me.

(User, Non-Developer Perspective)

+1 For a configuration option to make the menus always visible. The window title is a legacy and rarely provides useful information.

This solution would mean the developers could continue towards their goal of a non-menu-based world, and the rest of us could use the config option as a band-aid until the applications catch up with the platform

BTW I think unity is the best interface to come to the Netbook/desktop/laptop platform ever. Keep up the good work!

(User perspective, in reference to the version of Unity in 11.04)

Hiding the menu bar for non-maximised windows slows down accessing the menus because I don't know where a specific menu ('File', 'View', 'Tools' etc.) is going to be, so I have to move the mouse up into the menu and then 'browse around' to find the one I want. This is especially true for less-frequently used applications.

The 'browsing around' in the menu part is even more problematic because moving the mouse horizontally whilst keeping it in roughly the same vertical position - ie. without accidentally moving it below the menu bar, can be fiddly.

I'm not going to ask for a config option here, it needs to be fixed in the 'default experience'.

Please fixing this in the 'default experience'!

My girlfriend was desperately searching the menu bar!

on maximized windows
I see the window title and no menu bar, then see the menu bar where the window title is on mouse over
It's not consistent.
on non-maximized windows
I *don't* see the window title and no menu bar, then see the menu bar where the window title is on mouse over
To be consistent:
on non-maximized windows
I *should* see the window title and no menu bar, then see the menu bar where the window title is on mouse over *again*

window controls appear on top left in a non-maximized window
It's not consistent.
the launcher autohides and the window controls appear more to the right in a maximized window
To be consistent:
the launcher is always visible and the window controls appear on top left in a maximized window again

But what I really, REALLY want is:
the launcher always visible
on maximized windows
I see window controls and window title on top bar and the menu bar always visible below them
on non-maximized windows
I see window controls and window title on top of the non-maximized window and the menu bar always visible below them

And the advantage of my real approach is:
twice less vertical space occupied
(top bar, bottom bar, title bar, menu bar on maverick vs top bar and menu bar on oneiric)

In Oneiric the appmenu is really nice but the reported bug still persists.

Wouldn't it be possible to have the menu in the title bar of non-maximized windows so it would be consistent with the menu always being attached to the top of the window and save the space of a seperate menu.

I know that having the appmenu always in the panel is about design and a "clean" and simple desktop but in my opinion here 'intuitivity' outranks design. A detached menu istn't intuitive at all and even after using Unity since Natty was released I'm still mazed where to find the menu in non-maximized windows (sometimes I really wonder if an application had a menu or might have lost it).

I have to say, this is one thing that really annoys me about OS X. A problem I don't think people have mentioned is this:

When you have a maximised window it is unambiguous which window the global menu is associated with, since there is only one showing. However with unmaximised (windowed?) windows, it displays the menu for the *focused* window which may not be the one you are interacting with. If apps have similar menus (File->New Tab for example) it can get pretty confusing!

If the global menu is reserved for maximised windows things stay much more unambiguous.

After running natty and oneiric on my laptops and getting into unity, I tried oneiric on my desktop (2 screen setup with lot of "ssh" work on remote computers) in preparation for 12.04.

And I agree with most people criticizing the current application menu implementation.

Consider windows having menus sitting far away from the panel, even worse if auto-raise is on
You have to navigate around other applications or pass them quick to get to the right menu (not to one from a different application).
=> that's a design flaw

One may argue starting an application with UBUNTU_MENUPROXY="" helps here, however, one has to
* change every .desktop file => clumsy
* start apps from command line => that's what I did years ago and try to avoid thanks to a good desktop design
* remove libappmenu.so or change startup scripts in /etc/X11/Xsession.d => this is global for all logins on a system and thus wrong

Consider applications which are running one local instance and others remotely. Oh boy, local instances have application menus in the panel, remote instances on top of the window => huhu, not acceptable.

Here is one (non-invasive) solution which let users decide what they want. A better solution would be, however, to be able to select per application class or even by application state (full screen / not full screen).

What I did is to change the /etc/lib/Xsession.d/80appmenu* files to check if UBUNTU_MENUPROXY is already set, and leave it alone if so. So a user can disable application menus generally setting in her .xprofile.

Code is for /etc/X11/Xsession.d/80appmenu

if [ -z "$UBUNTU_MENUPROXY" ] && [ -f /usr/lib/gtk-2.0/2.10.0/menuproxies/libappmenu.so ]
then
 export UBUNTU_MENUPROXY="libappmenu.so"
fi

and similarilly for /etc/X11/Xsession.d/80appmenu-gtk3
if [ -z "$UBUNTU_MENUPROXY" ] && [ -f /usr/lib/gtk-3.0/3.0.0/menuproxies/libappmenu.so ]
then
 export UBUNTU_MENUPROXY="libappmenu.so"
fi

for .xprofile
UBUNTU_MENUPROXY=""
export UBUNTU_MENUPROXY

While I understand the design decision, I would also much appreciate options:

1. Default behaviour (Unity behaviour)
2. No global menu (Windows behaviour, clumsily settable by removing indicator-appmenu)
3. Always show global menu (OS X behaviour, not settable at the moment)

Also, it does not help that some applications appearently somehow circumvent the Unity behaviour by having their menus on the top of the window, for instance, Synaptic, while other applications have no menus at all.

Or "Only show global menu for maximized windows".

If I'm maximizing a window, I probably want the extra space. Otherwise, not.

Isn't this a duplicate of https://bugs.launchpad.net/ayatana-design/+bug/682788 ?