Improve Unity Global Menu

[Sesivany]

===+++ _____________________ ! ALL USERS ! _____________________ +++===
===+++ READ THIS BEFORE MAKING A COMMENT OR MODIFICATION +++===

IMPORTANT 1: Please don't post any "me too message"; use the "Does this bug affect you?" feature you can find a bit above this bug description on Launchpad.

IMPORTANT 2: Do not post anything if you haven't read all comments to verify that your point hasn't been made. If you feel tempted to stop reading because there are too many messages, that is a strong indicator that you shouldn't add even more comments. Developers have a tough time to find anything if you post redundant stuff. So please abstain from doing that.

=========
Global menu in general (not only in Unity) is very unergonomic on large screens (see the attached screenshot) because if you have a small window somewhere near the low right corner you have to move the cursor all the way up to to panel to reach the menu. I understand why the global menu was used for the netbook edition (it saves space and most windows are maximized), but since Unity is intended to be for the desktop edition there should be an option to switch to the traditional position of the app menu. It would be welcomed by many desktop users. Please try to find a solution for it that works.

A commonly suggested solution is:
 [ ] Global Menu on
 [ ] Global Menu off
 [ ] Global Menu only for maximized windows
The default is usually suggested as either the first (on) or last (on only for maximized windows).

-------------------------------------
Desired change:

Implement the 'Enhanced Menu' project for 12.10. This project will address the issue described in this bug and also issues described in the duplicates of this bus. Note this is the 'official' bug that tracks the implementation of this project.

The following options will be added to 'System Settings/Appearance':

-------
Menus
Location: Global/Local
Visibility: Hidden/Always displayed
-------

[Alex Launi (alexlauni)]

Hot key support is planned for the appmenu, so that should help some of the issue. We are still evaluating global menu on desktops. Thanks for your input.

[Pavol Klačanský (pavolzetor-deactivatedaccount)]

I think, this global menu could survive, but you need make apps in way, that users don't must go often to this menu (one button for settings in windicators place)

[nick rundy (nrundy)]

Global Menus (i.e., File Edit View etc) is NOT a good idea for a default setup on Desktop PCs. What is desirable though is the follow two things:

1.) when a window is maximized, the Titlebar merges into the panel so its contents are display in the panel. And when a window is not maximized, the user gets a traditional menu setup.

2.) applications should allow customization so that icons etc can be put (dragged whatever) on the Menubar (e.g., like Firefox presently allows). This can save enormous space. Applications like Nautilus, OpenOffice (LibreOffice) could use this functionality. Here's a screen shot of Firefox with everything I use to navigate the web all on the Menubar: http://img837.imageshack.us/f/screenshotdesktop.png/

[burli (mb-embedit)]

Global Menus are good for maximized Windows on small screens like Laptops or Tablet PCs.

On my 24" Monitor with 1920x1200 or, even more worse, on my dual screen desktop, global menus are horrible. And I can't use the autofokus function for the windows. It is extremly difficult or impossible to get from the window into the global menu.

My Solution, give the users the option to set:
 [x] Global Menu on
 [ ] Global Menu off
 [ ] Global Menu only for maximized windows

Set the default for screens smaller than 1MPix (1280x800 or 1366x768) to "Global Menu on", the default for bigger screens to "Global Menu only for maximized windows"

You won't have much friends with "Global Menu on" only. This is my impression from many comments in lots of news and blog posts around unity

[nick rundy (nrundy)]

I'd suggest:
[ x ] Global Menu on
[ ] Global Menu off
[ ] Titlebar only for maximized windows

[Cory (corisin05)]

When using Microsoft-Windows-7, I park the Taskbar (panel) on the leftside of the screen (where the Unity launcher resides). Therefore, I have NO Taskbar or Panel taking up vertical space. When I open an application (e.g, Firefox), I have only the application's Titlebar and Menubar taking up vertical space. Like nick described, I also put all Firefox controls onto the Menubar. Unfortunately, the use of Global-Menus would prevent my multifaceted use of the Firefox Menubar. This will then make it necessary to use additional bars, resulting in less vertical space:

      Unity layout (with Global-Menus enabled) showing Firefox maximized:
             1. Global-Menu/Panel
             2. Titlebar
             3. Navigationbar

      Windows-7 layout (with Taskbar on left) showing Firefox maximized:
             1. Titlebar
             2. Menubar/Navigationbar

However, if Unity does not use Global-Menus but instead merges the Titlebar into the Top-Panel, then the vertical space offered in Windows-7 can be matched:

      Unity layout (with merged-Titlebar & No-Global-Menus) showing Firefox maximized:
             1. Titlebar/Panel
             2. Menubar/Navigationbar

Another option would be to allow users to get rid of the Top-Panel and put notification icons onto the Unity-launcher (like a Windows-7 Taskbar). But if a Top-Panel is used, without a merged-Titlebar vertical space is reduced. The Titlebar is necessary so people can identify what window they are seeing, so it can't be omitted entirely.

One of the things I love about Windows-7 is its use of button-icons which allow me to park the Taskbar on the leftside of the screen; thereby, optimizing vertical space. Although Unity's design intends to save vertical space, its use of a Top-Panel presents a problem. The use of Global-Menus does not solve this problem--in some ways it makes it worse while introducing additional problems. But merging the Titlebar into the Top-Panel when windows are maximized presents a reasonable solution.

[Michele (mikelito)]

I second nick's suggestion. For un-maximized windows whether global menu is good or bad usability depends a lot on screen size, type of application, user's habits. For maximized windows, on the other hand, it makes a lot of sense in most cases.
Having the option of activating/deactivating global menu for maximized windows only would allow everyone to choose according to his own taste.

[Sesivany (jiri-eischmann)]

It would be nice to have an option, but I'm afraid it's not going to happen any soon because Canonical's design team don't do compromises. That's actually the main reason why they are not able/willing to work together with upstream. That's why I've given up this fight and will use GNOME Shell. It's not perfect, but it has at least its original design. My friend uses Mac OS X and placed the dock on the left side. It all looks exactly like Unity (top panel, dock, global menu, window buttons,...). I still thinks the open source movement has higher ambitions than copying someone else's design.

[Julien Olivier (julo)]

Actually, a global menubar is bad when your screen is too big, whereas a "normal" menubar (inside the window), is ALWAYS good - whether your screen is big or not. So, there is no reason to make any compromise: just remove the global menubar and everyone is perfectly happy :)

[Julien Olivier (julo)]

And, just for clarification, of course the global menubar is still a good idea when the window is maximized, so juste keep it in that case only.

[Chen Li (hardball-212010)]

I don't see how the menu rendered once per each window could be good for smaller screen. It doesn't seem that julian's position is a logical one; especially for applications that tend to be maximized all the time.

So basically the only time when window menu is better would be when someone has a very high Res screen (> 1920*1200), and the application being used is not conducive to be used in a full screen mode. That is an extremely small corner case; and global menu is better for the rest of the combinations of native res and apparently across the board, in terms of saving screen realestate, fitts' law, and aesthetics.

"Julien Olivier" <email address hidden> wrote:

>Actually, a global menubar is bad when your screen is too big, whereas a
>"normal" menubar (inside the window), is ALWAYS good - whether your
>screen is big or not. So, there is no reason to make any compromise:
>just remove the global menubar and everyone is perfectly happy :)
>
>--
>You received this bug notification because you are subscribed to unity.
>https://bugs.launchpad.net/bugs/682788
>
>Title:
> Global menu is not ergonomical on large screens
>
>Status in Ayatana Design:
> New
>Status in Unity:
> Opinion
>
>Bug description:
> Global menu in general (not only in Unity) is very unergonomic on
> large screens (see the attached screenshot) because if you have a
> small window somewhere near the low right corner you have to move the
> cursor all the way up to to panel to reach the menu. I understand why
> the global menu was used for the netbook edition (it saves space and
> most windows are maximized), but since Unity is intended to be for the
> desktop edition there should be an option to switch to the traditional
> position of the app menu. It would be welcomed by many desktop users.

--
Sent from my enTourage eDGe.

[Julien Olivier (julo)]

@Chen, having the application menu inside the application itself is always the best position for it because it's obviously the shortest distance from the application window, by definition... So, yes, having the menu rendered once per window on a smaller screen IS very good for the user. And, is you tend to have maximized windows, as I said, it's better to use the global menu. So, my solution would fit all the use cases perfectly.

[David Southwood (ds-mailbag)]

Generally global menu is ok, but the user does need the option to select the method which suits best.

In particular on my large screen I often have a lot of un-maximised gedit windows open - having to move the cursur all the way to the global menu every time is very frustrating.

[Chen Li (hardball-212010)]

Julien, I appreciate your sentiment;

But that is not a generally accepted view in HCI, and does not agree with
the basic biomechanics of the human body. Shortest distance does not
normally lead to the easiest way for the user to access some GUI element.
 Especially on a small screen, the easiest to hit is the location of the
cursor (e.g. right click menu); and a close second would be one of the
corner pixels of the display, and then the edges. Narrow menus under title
bars are actually some of the most difficult scenarios to deal with, and
really should never have been adopted for small to medium resolution
screens; which only carried over in places like windows or Gnome2 for
historical reasons and familiarity.

It is generally better to use some type of menu at the screen corner/edge if
the application window is sized to larger than a certain fraction of the
linear screen resolution in the relevant dimensions (depending on corner or
edge). The exact value is debatable, but the range is pretty well under
consensus by a lot of people. This means that with exception to very few
applications with excessively small windows (IM client, e.g.), the vast
majority of applications on a medium resolution screen will benefit far more
from global menus than from small, hard to hit menus under each title bar.
 This is without even mentioning the space savings and other benefits.

For very high res screens, I do agree with you, there are scenarios where
per window rendered menu system can be better. In those situations, it
would make sense, for example, on a 2560x1600 screen to have several
application windows occupy relatively small portions of the visible screen.
 But for these small corner cases, exceptions can be made at some
configuration during installation or user account setup. In all other
cases, it makes zero sense, and are prefered sometimes by certain users
simply because of the inertia of their computing habits. And we certainly
shouldn't try to force what you are suggesting on every user who have a
small to medium res screen.

On Sun, Apr 24, 2011 at 2:31 AM, Julien Olivier <email address hidden> wrote:

> @Chen, having the application menu inside the application itself is
> always the best position for it because it's obviously the shortest
> distance from the application window, by definition... So, yes, having
> the menu rendered once per window on a smaller screen IS very good for
> the user. And, is you tend to have maximized windows, as I said, it's
> better to use the global menu. So, my solution would fit all the use
> cases perfectly.
>
> --
> You received this bug notification because you are subscribed to unity.
> https://bugs.launchpad.net/bugs/682788
>
> Title:
> Global menu is not ergonomical on large screens
>
> Status in Ayatana Design:
> New
> Status in Unity:
> Opinion
>
> Bug description:
> Global menu in general (not only in Unity) is very unergonomic on
> large screens (see the attached screenshot) because if you have a
> small window somewhere near the low right corner you have to move the
> cursor all the way up to to panel to reach the menu. I understand why
> the global menu was used for the netbook editio...

[Sesivany (jiri-eischmann)]

"So basically the only time when window menu is better would be when someone has a very high Res screen (> 1920*1200)"
I think a menu for every window is better from 1280x1024.

"... That is an extremely small corner case..."
Does anyone at least have statistics what resolutions are used the most among Ubuntu users? Otherwise, these talks have no point. I think the global menu is not necessary and better for the most users (just my opinion based on what resolutions myself and my friends use). I would say that because of minority of netbook users, majority of desktop users is forced to use less convenient way to work with apps.

BTW there is one thing most people who discuss use of global menus omit. It's the fact that it makes unclear for users what belongs to the open app and what does not. I remember how difficult it was for my mum to differentiate between what' "inside" the app and what doesn't belong to it. It may sound strange for us, power users, but for many people, it's not easy to see borders of apps. Until now, app borders were defined by windows. Unity changes it and confuses new users even more.

[Julien Olivier (julo)]

@Chen,

what you said is probably right, but my guts keep telling me that the global menubar is a solution looking very hard for a problem :) I have still to find one user complaining that she had a hard time hitting the menu inside the window. However, I have already heard many users complain that they don't know where the menus are, with Unity...

[Andreas Grois (soulsource)]

Definitely need an option to disable the global menu bar for not maximized windows. It really sucks that you first have to change focus to enter a windows menu bar.

[dstaubsauger (dickerstaubsauger)]

i also vote for
 [x] Global Menu on
 [ ] Global Menu off
 [ ] Global Menu only for maximized windows

:)

[Graham Hawkins (grahamhawkins)]

I also would appreciate the ability to switch off the global menu bar for non-maximised windows, particularly for my 1600x1050 desktop. I use focus follows mouse & autoraise(*), and a global menu doesn't really work for me with several open non-max'ed windows.

BTW, I like the global menu a lot on my netbook - it really makes sense there.

Just my opinion... but not all users use the desktop according to the development team's original concepts, so it might be nice to have a bit of flexibility in how Unity can be configured.

(*)Since twm on SunOS 4 and yes - I am getting grey! I like this set up & I make my Win 7 desktop work the same way. Old dogs & new tricks :)

[KillerKiwi (killerkiwi2005)]

I have two 1920x1080 displays, global menu is good on my laptop.. not so much on the desktop on/off option defaulted to on would be appreciated. atm the moment of resorted back to awn

[tekstr1der (tekstr1der)]

I love global menu integration on maximized windows. However @2560x1440 resolution, not only is it a chore to move the pointer up to the menu area for non-maximized windows, but often I will mistakenly interact with the menu of a non-maximized window, intending to bring focus to & use the menu of a maximized window behind. This situation arises frequently and I find myself constantly searching for click-able white space in a non-focused application window to bring focus before interacting with their respective menu. Arghhh!

Between this usability issue, and not being able to minimize windows with the launcher (bug #733349), the unity interface sure requires a lot more time, thinking, mouse clicks, and pointer movement to complete otherwise simple tasks!

Here's hoping these two glaring efficiency issues are fully addressed with Oneiric.

[tekstr1der (tekstr1der)]

Oh, since this is an "opinion" bug, my vote for configurable options:

 [ ] Global Menu on
 [ ] Global Menu off
 [x] Global Menu only for maximized windows

[Kenton Varda (temporal-gmail)]

My opinion: Fitts' law is overrated and people are taking it as gospel while ignoring much more important factors.

Fitts' law says that it is easier to move the mouse to menus located at the top of the screen because you don't have to carefully aim in the vertical direction -- you can just ram it up there and let it hit the top of the screen. Sounds logical, right? Well, consider the following:

1. Have you ever found it difficult to click on in-window menus? Is this actually a problem? I really don't think it is.

2. How often do people actually use menus these days? The menus are the place where developers shove all the rarely-used options. The actual action takes place inside the window. It seems like we should be applying Fitts' law to something that is actually frequently used. But no one is creative enough to figure out how to take arbitrary window content and shove it to the edges of the screen. It seems like people apply Fitts' laws to menus just because they are already traditionally located at the edge of the UI.

3. Context. Context context context. The way to pack a lot of functionality into a user interface without confusing the user is to make sure that each function is located contextually, so that the user can zero in on the thing they want to do while ignoring whole swaths of the UI that they know are unrelated to their task. By located the menu at the top of the screen, you are ripping it out of the logical context in which it applies. This is *confusing*. Now it looks like that window has no menus, and lots of functionality seems to be missing. Why on Earth would I expect a program's functionality to be surfaced way off in a separate bar which otherwise appears to be part of the desktop environment?

IMO, maintaining context is priority #1 for any UI, vastly outweighing Fitts' law. Frankly, Fitts' law is a funny quirk of the display surface that should be ignored, because trying to satisfy it almost always conflicts directly with maintaining context.

All that said, I think that merging the menu into the top bar is a fine idea when the window is maximized. You are not losing any context there, because the entire screen is being devoted to one application. This also happens to provide the perfect balance between small-screen and big-screen issues, because on small screens people tend to maximize apps, whereas on big screens they don't.

Anecdotally, I used OSX as a primary desktop for several years, and one of my main reasons for ditching it was the global menu, which I could never get used to. Whenever I had to do anything menu-intensive it became a huge pain (literally, in my wrist), and I often found myself accidentally manipulating the menus for the wrong application because I didn't realize which window currently had focus (it's not so obvious on a large screen). I do hope this becomes an option in the future; until then I'll have to stick with gnome 2.

[Michal Predotka (mpredotka)]

Kenton Varda, you don't have to stick with gnome 2 in order to not use global menu. Just remove "indicator-appmenu" package. I've done that and Unity is usable for me.

[Aldo Nogueira (aldo-nogueira)]

I can see no objection to have global menus only for maximized windows. It solves the problem proposed by Sesivany's screenshot. At least, it should be configurable.

[Eugene Crosser (crosser)]

I think that merging the application menu with titlebar and "panel" works great for maximized windows. It saves space and removes clutter.

But for me at least, global menu is highly detrimental when working with non-maximized windows. The worst thing is not even the long travel of the mouse pointer, but the need to move the eyes to a completely different part of the screen. It costs me loss of focus. When the menu is inside the window, the contents stays within peripheral view while I operate the menu, and I believe that it helps to return attention to the object much faster.

Please consider returning the app menu inside the windows when they are not maximized, or at least have such behavior as an option.

[Nandu Raj (nndurj)]

I love the global menu. It's perfect for my 1366*768 laptops screen. But when using multiple unmaximize windows the classic menu bar is better than global menu

[वैभव Vaibhav (vaibhav.vaish)]

Having global menu enabled only for maximized windows, IMHO solves the problem reasonably enough.

[GrantMcLean (grant-mclean)]

I have tried Unity on both small screens and a moderately large screen and I have not seen any advantage in the global menu except when the current window in maximised. When working with multiple windows I find there is a cognitive load associated with my eyes having to scan over the other non-active windows to get to the top right. Having the menu options in close proximity to the app I'm working with allows me to keep focused (like Eugene Crosser). I also really like focus-follows-mouse (although I don't use auto-raise) and that doesn't work at all with the global menu if your mouse has to pass over a different app on the way to the menu bar.

A related thing that I can't believe nobody has mentioned is that the global menu options are not even visible at all until your mouse is hovering over the top bar (is it just me, is there something wrong with my setup that causes this to happen?). This seems like a real barrier to usability - how are people supposed to know there are menu options if they can't see them?

[Andreas Grois (soulsource)]

@Kenton: Fitts Law also doesn't apply to configurations where users set their Desktop borders as active regions for doing "something", the most trivial thing would be to use them to switch virtual desktop.

[Michael Flaig (mflaig)]

@Grant: The only way to see the menu atm is to move the mouse cursor to the top panel or press and hold alt key. And while you press alt the next step would be to press f or whatever other key is marked with an underscore.
No problem for me - using a 30" screen with 2560x1600...

[Michael Vogt (mikeyvogt)]

We have OS X at work, and I can't tell you how often people get confused by the global menu bar. Users accidentally change focus to a different window, and end up using menus for the wrong program. Separating what the user sees as his or her "application" (i.e. the application window) from the menus confuses users, and for very little benefit. When the file menu is included in the window with the rest of the application, such mistakes are nearly impossible to make.

As a user of OS X and Ubuntu, I'm most disappointed by this decision. It's my least favorite part of OS X (nothing else even comes close), and I would be a much happier Ubuntu user if I'm given an easy option for turning it off in future versions.

[Daniel Planas Armangue (daniplanas.a)]

the problem it's not the position, the problem is menubars itself. Aplications like calculator doesn't need menubars. And aplications like gimp ( it oviously needs) normaly works on maximized ( or very short distance) modes.

[tekstr1der (tekstr1der)]

This is clearly a confirmed usability issue. Fact. Not opinion.

[Danillo (danillo)]

I really like the global menu idea, but for maximized windows only. The main argument used for it is to save vertical space, but when the window is not maximized it has the downside of demanding too much mouse traveling, and when several non-maximized windows are open and one has to constantly move among them there is a lot of confusion.

The main problem is for software like Gimp for example. By default, it has three windows and lots of menu options, and there is heavy use of menus and changes of window focus. Yes, a single window view will eventually come, but several people like the multiple windows and will keep using it. Besides, this is just one example out of several other cases and softwares with constant window changes and heavy use of menu.

The best solution would be the option to control global menu behavior like suggested:
[ ] Global Menu on
[ ] Global Menu off
[x] Global Menu only for maximized windows

[manny (estelar57)]

menus by default on small windows (unmaximized) still makes the app ugly or adds visual clutter.

so there were some mockups that tried to solve this (hide the menu to avoid clutter, but let you toggle it to be used in the unmaximized window):

mockup1; windicator (minute 4:32; i would probably use a cog icon like chrome):
http://www.youtube.com/watch?v=0O6v9miJKGI

mockup2; attached to window bar:
http://www.webupd8.org/2011/02/unity-mockup-menu-integrated-in-window.html

any of the two would probably work, and make the global menu in ubuntu, 1 step ahead of mac + the space saving, less visual clutter and usability of the traditional one.

[Farran (farran)]

I made some mockups back in April which match what many people in this thread have suggested - Global Menu only in maximised windows. They are very similar to mockup 2 in the previous comment by manny . The difference in mine is that the whole window is the same colour as the title bar, and all empty space in the window (ideally the space which is the same colour) can be used to drag the window around.
I have also mocked up a few options for when the menu bar is longer than the space available in the title bar.

These changes would give us the usefulness of the 'Global' menu - space saving - but also keep the usability and ergonomicness of having the menu bar close to the window.

Here are my mockups - feel free to comment and criticise so I can make better ones: http://anaershadowynomaly.deviantart.com/gallery/29691776

[manny (estelar57)]

@farran

love them.

of course am pretty sure they would want the menus hidden by default.

would be nice to also see some type of windicator to toggle "always on" visibility on an app you may use frequently like gimp.

but if they just add the menu to the non maximized app in the window border would be more than enough for now

[manny (estelar57)]

if the solutions found in the mockups are implemented, ubuntu could also use a smaller and better looking wing type panel:

https://bugs.launchpad.net/ubuntu/+source/unity/+bug/692921

[Matt Sturgeon (mattsturgeon)]

I vote
  [ ] Global Menu on
  [ ] Global Menu off
  [x] Global Menu only for maximized windows

[uidb4056 (robert-dols)]

I also agree with Matt Sturgeon,

I vote
  [ ] Global Menu on
  [ ] Global Menu off
  [x] Global Menu only for maximized windows

[Marja Erwin (marja-e)]

I use menus pretty often, and use them for just about everything when learning new software. So I disagree with the idea that menus aren't important. I don't have any trouble with global menus, but I used to use a Mac [which has global menus], and I used to have a malfunctioning Alps touchpad on my current machine [which meant that, among other problems, it was hard to get fine motions with the cursor].

There is now a patch for the Alps, but there is bound to be trouble with another closed-source touchpad, mouse, or other device.

I have one problem with the global menus - that the menus for any one application cover up the menus for the desktop environment. Apple moderates this using the Apple menu. Unity puts the shortcuts menu there instead, and the shortcuts menu is a pain to deal with.

[Almufadado (almufadado)]

My Unity experience is starting to be annoying !!

1st - The window's Menu is the most important thing of a dialog that is open
    a ) when it is maximized the menu is close to the frame of the window but the buttons are place in the top left
    b ) when it is in a window, while multiple windows are open, then starts the confusion because i can have two instance of the same application (ie firefox ) and the menu it closer to the bottom maximized rather then being closer to the on top window
  c ) when multiple dialogs are windowed this created the ultimate confusion because i must search for an empty space to click on (and some do not have it or is a "sniper" task !)

The old (how dare ?!?!?) task bar where the open applications are easily reached with a single click and mouse movement are now lost in the haze of a monstrous bar where everything mix in a soup of icons (when they fold and unfold) and the present application I am using is lost somewhere in the bottom and then i have to roll down, hope it stops where I want it to be, and then pray for it not to fold again or slip so I have to search again for it.

If the intention is to produce a visual, icon based, accessible bar then it must rely on the mouse rather than than the keyboard (yes, i have th alt+tab).

Other thing include :

- > In the notification bar, unity is forcing the user to have only some icons (I NEED to have a a networking monitoring app, like to see if the cpu is not overloading, etc)

-> the administration menu is ... is not .. was a beautiful accessible thing of the past (sniff !) oh sorry is buried under 3 click in game of now in the left now in the right !

-> the notification icons do not fix the menu forcing the mouse button to be pressed, and as the buttons are so small it moving the mouse if skips to the other side menus

-> the "game" of now in the left, now in the right : the window's buttons, the menus are always changing places

-> last but not least is the open app indicator in the unity menu which is a small pointer which is neither helpful (because of the size and being a shape sifter

PS : Is Ubuntu still intended for personal desktop computer of is the new "unity" intention of turning my PC into a IPhone ?
PS 2 : In case this is not the right place for this comments, I am in advance truly sorry.

[manny (estelar57)]

@Almufadado (almufadado)

the first part is ok, as this bug report is related to the menus/global.

for the other parts is best to have them in separate reports as they're not very relevant here.

[GonzO (gonzo)]

I also vote "[x] Global Menu only for maximized windows".

Having said that: I generally LIKE the Global Menu... however, I genuinely *hate* that it is hidden until mouseover. There is just not enough visual data to suggest that it is under there somewhere, and it removes the ability to just click on what I want (instead having to discover where the menu entries are first).

If we *must* have a global menu, let's please stop making it invisible. That's flashy, but makes the desktop harder to use.

[Chris Snider (crms1496)]

There could be something like the global menu system, in which the menu shares space with the title bar in minimized and non-minimized modes. That way, vertical space will be saved and the menu system will be ergonomic for users with large screens.

[Chris Snider (crms1496)]

Of course, the menu would be hidden until mouseover.

[Dudu.exe (stuffmail)]

I hate how title hides menu in global menu. this is unintuitive, if you not a poweruser

and i have to have the close button hidden, sometimes i want to close a window behind a smaller and not maximed windows. you cant close the window until you click that windows to give it focus so aftar you have to move the mouse to title bar to make the buttons show up.

[Indian Art (goldfish-aol)]

Wouldn't it be great if Ubuntu brings an optional & customizable bottom
panel back. This could be done in 12.04

-----Original Message-----
From: Dudu.exe <email address hidden>
To: goldfish <email address hidden>
Sent: Wed, 19 Oct 2011 9:20 am
Subject: [Bug 682788] Re: Global menu is not ergonomical on large
screens

I hate how title hides menu in global menu. this is unintuitive, if you
not a poweruser

and i have to have the close button hidden, sometimes i want to close a
window behind a smaller and not maximed windows. you cant close the
window until you click that windows to give it focus so aftar you have
to move the mouse to title bar to make the buttons show up.

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/682788

Title:
  Global menu is not ergonomical on large screens

Status in Ayatana Design:
  New
Status in Unity:
  Confirmed
Status in “unity” package in Ubuntu:
  Confirmed

Bug description:
  Global menu in general (not only in Unity) is very unergonomic on
  large screens (see the attached screenshot) because if you have a
  small window somewhere near the low right corner you have to move the
  cursor all the way up to to panel to reach the menu. I understand why
  the global menu was used for the netbook edition (it saves space and
  most windows are maximized), but since Unity is intended to be for the
  desktop edition there should be an option to switch to the traditional
  position of the app menu. It would be welcomed by many desktop users.

  A commonly suggested solution is:
   [ ] Global Menu on
   [ ] Global Menu off
   [ ] Global Menu only for maximized windows
   The default is usually suggested as either the first (on) or last (on
only for maximized).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ayatana-design/+bug/682788/+subscriptions

[pelle.k (pele2)]

The mockups by farran in comment #38 is EXCELLENT.
IMHO it solves all problems with a traditional menu taking up too much space in the main window chrome, while being fairly accesible without first focusing the window you wan't to access the menu from, like the appmenu-indicator forces you to do currently. Window title is still draggable. And, to be perfectly honest, a window so small you can't see the whole menu is a corner case IMHO, and even then you can expand the full menu by hovering it or so, like in the mockups.
From what i understand, we still need client-side window borders for this to happen though (correct me if i'm wrong).

If implemented, the top panel becomes mostly empty space though, so in that respect, we then have another mostly unused area of our screens that could be put to better use. Of course, you could always use a "wing panel" of sorts, and allow full screen windows to occupy roughly ~ 40-60 pixels more than before (menubar and top panel). Perhaps it would even be an idea to move the indicator system to the sidebar, and have that as the sole panel/bar on the desktop window. Maybe i'm pushing it too far? :)
By now, i've probably strayed quite far from the scope of this bug report, but it makes sense to draw people a picture of a possible outcome of the rationale to redesign the menu system, don't you think?

[manny (estelar57)]

Wow, almost 100 people, very few bugs have this many people...

I wonder how many more are needed for someone in the design team to give a little feedback of what can be done this upcoming cycle or when can we expect this will be looked at.

[Peter Silva (peter-bsqt)]

Check out this one:

https://bugs.launchpad.net/unity/+bug/674138

same bug, 70 (presumably distinct) people.

[tekstr1der (tekstr1der)]

@Peter: Definitely NOT the _same_ bug, but it is related to the issue discussed here for sure.

[manny (estelar57)]

@Matt, If global menus get disabled for non-maximized to fix this bug, then what are the possible options or solutions?

I think we also need to point them out.

*Possible solutions for non-maximized windows:
   [ ] Menu on panel for maximized; Normal menu for non-maximized
   [ ] Menu on panel for maximized; Integrated on windows title-bar for non-maximized (see mockup in #38)

If anyone else has anymore proposals feel free to do so.

[Peter-Alexander (pp78)]

I like the mock ups from post #38.

I generally love the global menus. Sometimes it is not so good because the wrong application has focus and I have to activate the right window to access the menu.

I hate the "traditional" window menus. They unnessasarily take up screen space and additionally they aren't beautiful.

I haven't intensly thought about it but I like the idea of combining the title bar and the menu bar in not maximized windows. (post #38)

[Peter-Alexander (pp78)]

After looking again at the mock ups of post #38 I would prefer to make the combined title/menu bar more like it is now in global menu. Only show the title in the bar an on mouseover show the menus only. Because this is much more beautiful.

[Michal Predotka (mpredotka)]

Peter-Alexander, some people actually _use_ menus and programs, not only they look at the desktop thinking how beautiful it is.

[manny (estelar57)]

>After looking again at the mock ups of post #38 I would prefer to make the combined title/menu bar more like it is now in global menu. Only show the title in the bar an on mouseover show the menus only. Because this is much more beautiful.

@Peter-Alexander

that would be the idea.

menus to show on mouseover, and since they attached to the title-bar, they are easy to access, which would fix this bug, be less confusing and keep things as nice looking as they are now.

[rawphi (raphael-ist)]

i did a quick hack of the appmenu-gtk package, to show the menus locally, when windows are unmaximized:

http://www.youtube.com/watch?v=6j82wq0SlvY

the global appmenu always is active. imho this would be a good compromise to predictability

you can also see the problems the global appmenu creates in combination with focus-follows-mouse behaviour ;)

i attached a patched binary package if somebody wants to try it out too

[cmat (cmat555)]

The global menu seems confusing to some users I've introduced to Ubuntu. Some of them never got the hang of it without me pointing it out. I suggest some sort of hint to the presence of a menu, but I have no idea what it could be. I vote having the menu localized to a frame when not maximized. I think the global menu is the only real issue people I know have with unity, otherwise they are quite impressed.

Also the global menu doesn't let me 'bee line' the cursor to a menu item. I have to move my mouse to the bar (in the approximate location with practice and memorization) and then adjust its position if it wasn't on target. Seems to be some wasted effort there.

[Romano Giannetti (romano-giannetti)]

rawphi: great idea, it's what I am advocating for since first day 1 of Unity. There is now a little group (I hope growing) asking for something to be done for having a better global menu experience... https://launchpad.net/~focus-follows-mouse

see also bug #778418, bug #734325, bug #674138

I hope your patch could be integrated in all the app-menu flavors --- count on my vote for it.

[Aaron Mayse (eyeless1)]

Rawphi: liked the demo for your patch (not downloading it myself just yet because I'm trying to fix a host of other problems related to the upgrade, but I appreciate the work).

The irony here is that everyone is talking about fitts' law when advocating for global menus, but there's a problem: Fitts' Law doesn't apply to Unity's global menus. Go to the extreme upper-left corner of your screen--the part Fitts says is many times easier to find than a nearby window target--and click. *Nothing happens*! The Close Window button is right next to your mouse on maximized windows, but even then it's not in the actual corner, so nothing is activated by that click anyway. This is in direct contrast to, say, Apple's OSX, where the apple menu is actually located in that corner, and actually does something when you click in that corner. Since you're not locating the menu in the corner, but rather at the screen edge, you don't degenerate into Fitts' Law with the target of infinite size. The target is not infinitely wide in the horizontal direction, so you have to do more complicated math to determine the actual speed to get to the target.

So, even if global menus were a good idea for non-maximized windows--and I agree that they are--the way they are currently implemented still doesn't help that much. Even further, we really need something in the actual corner for Fitts' Law to really apply, and really there ought to be something there that isn't a Close button, maybe a task/workspace switcher?

Another significant point: when looking to apply Fitts' Law, you can't just look at the mouse pointer; you also have to look at physical eye movement. Here is where the case for large monitors needing local menus for non-maximized windows really comes into focus, because for the eye, a screen edge/corner is *not* infinite width! "Pointing" at that global menu with your eyes across a large monitor's screen may take 2-2.5 times as long or longer. Now, this wasn't really such a big deal back in the days of 15-inch monitors, but these days 23-24-inch monitors are fairly common, and multiple monitor setups will only become more common as even integrated graphics become capable of driving multiple displays well.

[Matty Lamb (mooosepurchases)]

I also agree that the user should have the option of turning the global menu off, on, or on only when maximized. This would improve customization of the unity interface, which is sadly lacking.

One reason the global menu is annoying is that it collapses all of the menus and only displays the application name. This makes it difficult to find a particular menu, and it is visually distracting to have the top left corner constantly shifting whenever you mouse over it. Global menus work on Mac OSX because they are in the same place for every application, making it visually consistent and easily navigated. Of course, some people doubtless like the aesthetic of hiding the menus, so again, the user should be given a choice.

Choices are good!

[Pedro Bessa (pedbessa)]

The following makes Unity have a consistent look and save vertical space.

maximized window
window title on top bar, global menu appears where window title on top bar is on mouse over the window title on top bar

non-maximized window
window title on top of the window, global menu appears where window title on top of the window is on mouse over the window title on top of the window

[Romano Giannetti (romano-giannetti)]

+1 on Pedro's proposal

[Marco Trevisan (Treviño) (3v1n0)]

That had been proposed through a mockup (by andyrock IIRC) some months ago.
The problem is that is hard to manage the resized windows that have menu-bars longer than their own size.
Grouping the menus could be a solution, but it's quite hard to do in the current state (also for global menu).

Also, this would make moving a window (dragging it from its top bar) harder.

I think we need some more input from designers on this point.

[manny (estelar57)]

@Pedro Bessa (pedbessa)

check comment 38:

https://bugs.launchpad.net/unity/+bug/682788/comments/38

[Romano Giannetti (romano-giannetti)]

@Marco: I see, you're right.

So I think that the OP suggestion is still the good one. Have (at least optionally) global menu only for maximized windows.

[Pedro Bessa (pedbessa)]

"Also, this would make moving a window (dragging it from its top bar) harder."
We can't have a global menu on non-maximized windows. Let's not have a global menu on maximized windows. Then, the look will be consistent.

You don't need the global menu. Maverick had four vertical bars (top, title, menu, bottom), Natty had two vertical bars with title and launcher always visible (title and menu). You halved the vertical bars! What an achievement! Apple and Microsoft didn't do that! Please, be satisfied!

Google recently phased out lots of apps and app features that didn't work. Since you're attached to the global menu, first let people toggle it on and off in 12.04, then phase it out in 12.10.

[Marco Trevisan (Treviño) (3v1n0)]

IMHO the only possible solution is something like this one: http://www.webupd8.org/2011/11/oxygen-appmenu-replace-menu-with.html

[manny (estelar57)]

@Treviño

Very nice, I actually like it and maybe the menu could appear on mouse over instead of click ?

looks good on gtk apps too:

http://minus.com/lbq3ka2PRj4EKV
http://minus.com/mbfBJxhgzj#2

It would also work well on maximized windows and the bar elements can hide as they do now. Or maybe could just stay horizontal as it is now since people dont really have problems with it when is maximized.

- Another idea (by looking at that kde plugin):
for non maximized, is that the menu could show *horizontally* (instead of vertically) over the window bar only when you mouseover ( or Click ) the *name of the app*. The window title would then disappear and reappear when you move the mouse off.

I think that might also be another alternative so they look more consistent and still behave like the plugin you mentioned and possibly solve the issue.

[Romano Giannetti (romano-giannetti)]

I like Marco proposal. I see still a place for a "normal" menu for unmaximized windows, but the appmenu thing is nice...
Will it work with Gnome shell?

[manny (estelar57)]

forgot to link the comments to the pics:

http://www.webupd8.org/2011/11/oxygen-appmenu-replace-menu-with.html#comment-371672591

@Romano

I think is kde only for now, but seems to work also with gtk apps. maybe needs some tweaking or porting.

[Pedro Bessa (pedbessa)]

Guess what? The global menu isn't dead! I like Treviño's proposal too! It can motivate all apps to have an app button like Chromium!

Make the app buttons customizable to programmers, not to users. If it isn't customizable to programmers, menu items will be one more click away (one File click becomes one Menu click, then one File click). If it is customizable to programmers, programmers will try to make an app button like Chromium (with most important items that were going to appear in a deep level actually appearing in the root level).

[Robert (open-source-software-rb)]

What about complex applications like the GIMP? Those type of applications can never implement a one button menu and still be ergonomical and productive.

Look at what GNOME will do with the 3.4 version, they will implement a single button interface just like you proposed for the menu but they will also retain traditional menus for complex apps and not hinder the user's productivity.

[manny (estelar57)]

@Robert

That's why i proposed a similar approach, but with a few tweaks (appear on mouse over instead of click and possibly an horizontal layout instead of vertical to match better the current behavior but for non maximized):

https://bugs.launchpad.net/unity/+bug/682788/comments/73

that should make it very ergonomical.

Anyway with the new gimp's "monowindow" coming soon:
http://www.omgubuntu.co.uk/2011/08/gimp-2-7-3-released-working-single-window-mode-layer-groups/

would be rare that it wouldnt be used fullscreen, so the menu (fullscreen) would have the same behavior it has now.

Remember this bug is affecting just the non-maximized windows.

[manny (estelar57)]

Also in my case I dont see a problem with having both the global menu we have now and the vertical-menu/button attached to the non-maximized windows (Marco's idea). Since they both are hidden by default. But when you hover you would activate either one.

Then when you maximize the window only the global menu would be active, since the panel and window bar become one.

Seems like a faster implementation and would still solve the problem for this cycle. Then on upcoming cycles (or when they get more time) it could be tweaked in various "creative" ways.

[Pedro Bessa (pedbessa)]

adding wingpanel as inspiration to the discussion
"It’s simply a sexy panel that houses indicators. It shall float above windows, so that it steals space from the window titlebar."
look top right, not bottom center
http://www.omgubuntu.co.uk/2010/12/wingpanel-elementarys-slick-new-space-saving-panel/

[manny (estelar57)]

@Pedro Bessa

yea, fixing the bug with some of the proposals mentioned here, could also open the possibility to having a much smaller and better looking panel (aka "wing style" panel) in the future.

[Pedro Bessa (pedbessa)]

later, if people dislike the app button, because of the extra click, phase out the global menu

[manny (estelar57)]

>later, if people dislike the app button, because of the extra click, phase out the global menu

it doesnt have to be an extra click. it could be made to reveal on hover.

also since both menus are invisible and dont clutter the screen , both options could be available for unmaximized.

[Danillo (danillo)]

I loved the suggestion of an Oxygen-style app button menu! Fenryxo's mock-ups are simple but wonderful. This would make Ubuntu's global/app-menu centuries ahead of OS X's global menu.

I think this would solve almost every single issue users has with the current global menu while retaining all of it's advantages, plus having an increased discoverability (since it would not exactly be hidden, it would be indicated by a window button). It could also have the option of being customized for showing on hover or upon clicking according to need.

By the way, there is another bug report filed to this bug. Check bug # 900418.

[Pedro Bessa (pedbessa)]

How will the patch be released?
- Update Manager's install updates?
- A ppa with Unity?
- Distribution Upgrade to Beta Version?

I want to use a consistent design in 12.04!

[Dennis Shimer (dshimer)]

As a basic but everyday user I am totally committed to Unity, have been since 11.04, and find it growing on me. I use global menu's but still don't like them for non-maximized apps. I will never understand why it is better to have the menu disappear until you mouse over. I'll keep using it, but am not sure at this point I'll ever really love the current configuration.

Likewise I have converted 7 total windows users in 3 families (started at 10.04), all of whom are very non-technical. Nobody has complained about anything in the upgrade and seem to get along fine, however the one biggest discover-ability fail goes to finding the menu. I consistently hear "wait that wasn't there a minute ago", "why does it go away" and such.

[Tanker Bob (tankerbob)]

The global menus is my major gripe with Unity since I found a patch to move the dock from the left to the bottom of the screen. Global menus kill the mouse-over focus functionality which I use heavily. The global menu for the last window passed over with the pointer appears rather than the menu for the intended app. Since almost all apps open against the top panel, it becomes a tight rope act to tread carefully around other windows to get to the menu for a smaller window that isn't against the top panel. I will try the patch in comment #60. That behavior should have been the default all along. I appreciate the suggestion earlier of uninstalling the offending indicator, which I may use if the patch doesn't work out.

My vote:

   [ ] Global Menu on
   [ ] Global Menu off
   [X] Global Menu only for maximized windows

If this will eventually be user-selectable, then the default should be the global menu only for maximized).

[Yassine ELOURI (yassine-elouri)]

I quite like this idea posted here on webup8:

http://www.webupd8.org/2011/02/unity-mockup-menu-integrated-in-window.html

It also reminds me of how windows 7 handles menus (click Alt to toggle on-off)

[Pedro Bessa (pedbessa)]

+1 on http://www.webupd8.org/2011/02/unity-mockup-menu-integrated-in-window.html 's proposal
- you drag and drop the window by holding down the window title
- you don't add an extra click like the app button does

[Kenneth Camargo (kencamargo)]

My two cents: I believe the key issue here is one of *choice*. As can be gleaned from the various (and varied) comments on this request, there are far many preferences than might be thought of by a design team, no matter how brilliant. I think the best approach is letting the user choose; my favourite configuration would be to have the global menu off, or at least limited to maximized windows.

[Michael Rybinsky (lyset)]

[X] Global Menu only for maximized windows

[Ante Karamatić (ivoks)]

I must say I prefer unity with package from comment 60 and these options:

gconftool-2 --type string --set /apps/metacity/general/focus_mode mouse
gconftool-2 --type boolean --set /apps/metacity/general/auto_raise false

Package without these changes or changes without the package make no sense, but together they are great (imho).

[Pedro Bessa (pedbessa)]

"My two cents: I believe the key issue here is one of *choice*. As can be gleaned from the various (and varied) comments on this request, there are far many preferences than might be thought of by a design team, no matter how brilliant. I think the best approach is letting the user choose; my favourite configuration would be to have the global menu off, or at least limited to maximized windows."

My bug report affects you -> https://bugs.launchpad.net/unity/+bug/891770

http://www.webupd8.org/2011/02/unity-mockup-menu-integrated-in-window.html + https://bugs.launchpad.net/unity/+bug/655184 = my favorite way

[NeoRazorX (neorazorx)]

[X] Global Menu only for maximized windows

[Pedro Bessa (pedbessa)]

"it doesnt have to be an extra click. it could be made to reveal on hover."

If I go to click something in a window, but hover its app button, the menu appears and I misclick a menu item.

[AlejandroÑext (alejonext)]

Well, I think my English is not good, but still I write. I utlizando Ubuntu notebook, and is best AppMenu. By increasing the amount of space intereacion with the application, not that I liked is desplasarme up to the top to make a small modification in the application.

Which would be nice that peuqeñas, applications are within the window Appmenu that means voting

[X] Global Menu only for maximized windows

By which I think is the best way to sulucionar palicacion problems such as having small windows as Empathy and Calculator. And could give the difference between Mac, Windowns with Ubuntu!

[manny (estelar57)]

>>"it doesnt have to be an extra click. it could be made to reveal on hover."

>If I go to click something in a window, but hover its app button, the menu appears and I misclick a menu item.

@Pedro don't contradict yourself.

you hover with the current menus and also would hover with:

http://www.webupd8.org/2011/02/unity-mockup-menu-integrated-in-window.html

do you "misclick" now ?

It would be even less likely to accidentally hover on the "menu button" proposal, because is not invisible and you can see the name.

[Pedro Bessa (pedbessa)]

I don't mind having an extra click much.

[Greg Merchan (gregory-merchan)]

Apple sells iMacs with screen sizes 1920x1080 and 2560x1440, and the Thunderbolt display at 2560x1440. It is not the case that a global menu bar is not ergonomic on large screens.

It is the case that it is not well implemented in Ubuntu, for a few reasons already mentioned:

1) The menu is not visible until the mouse is there, so I don't know where I'm going. Also, the change to a menu on mouse-over is jarring.

2) The top-left corner is now a dead space. I can't aim for the corner, click, and move right through the menus.

3) Most non-MacOS apps are too menu driven. Developers on other platforms have for years had menus in the application windows and thus relied on them too heavily.

4) The difference between the active or focused window and the other windows is too slight. (This is something of a problem on MacOS now too, I believe.)

(It's late here. I think I forgot a couple.)

I'm happy the design team has been intransigent on this matter. It's one reason I'm sticking with Unity even though I like Gnome Shell's code more. (I would love to see Unity implemented as Gnome Shell "extensions" instead.) That Apple menu bar is not only right ergonomically, but culturally too: it encourages better application design by pushing development away from menus and toward direct manipulation. As unpopular as it may seem here with almost 100 comments against it and with various web pages devoted to how to disable the menu bar, the system that has always had it has the fastest growing user base of all.

[Giorgio Wicklein (giowck)]

I deeply agree with Greg,

[X] Global Menu on for all windows, but visible (not hidden => visible also if the mouse doesn't hover it)

[Romano Giannetti (romano-giannetti)]

@Greg, @Giorgio: I humbly disagree. I think you are using "click to focus" model. I (and much others here) are using focus-follow-mouse, which for me is fundamental when editing various related code in multiple windows.

With focus-follow-mouse, global menu is a no-no, I suppose you can see why: you have to go to the upper left corner *avoiding* other windows in the way. And no, I hope that the solution wouldn't be to cull focus option (although in this crazy "you shouldn't personalize/choose anything" frenzy all is possible).

I understand that MacOs do some thing well, but please let people have options... and the idea is not to clone Mac, I suppose, otherwise the best solution is going out and buying one of it ;-)

So having an option "global menu only for maximized windows" (option, optional, not forced, you shouldn't change your configuration) is a nice, democratic, all-inclusive solution.

[manny (estelar57)]

I like the global menu *even less* on a mac.

at least we save some space on fullscreen with the current implementation.

However, i think ubuntu doesnt want to clone mac, but create something that is far better.

[manny (estelar57)]

hmm, back to the menu-button, this here cool concept mockup integrates something similar and seems to go well with ubuntu's future multidevice vision:

http://4.bp.blogspot.com/_JSR8IC77Ub4/TTRvnGBMuxI/AAAAAAAABoI/V4uAumdAngs/s1600/ubuntu_theme_mockup_v4_by_rustedthorn-d3738bm.png

http://rustedthorn.deviantart.com/art/Ubuntu-theme-mockup-v3-192940783

http://rustedthorn.deviantart.com/art/Ubuntu-theme-mockup-191747488

[manny (estelar57)]

ok, i made an horizontal and persistent variation of the vertical-kde-appmenu:

On:
http://madjunir.deviantart.com/art/ubuntu-menu-button-un-maximized-windows-273062518

Off:
http://madjunir.deviantart.com/art/ubuntu-menu-button-un-maximized-windows2-273062844

Is like what you see on comment #60:
https://bugs.launchpad.net/unity/+bug/682788/comments/60

But you toggle it only when needed so it keeps things nice looking when not needed.

Is also persistent so is easy to work with in apps like gimp, LO, etc..

Note the green button i borrowed from another mockup, so it could be made something else or look more like the kde appmenu.

Another positive thing is that is not too hard to implement in a shorter period, unlike some other concepts. Hopefully we can see something done this cycle.

[Romano Giannetti (romano-giannetti)]

@manny: that's a great solution. Nice!

[Danillo (danillo)]

"Apple sells iMacs with screen sizes 1920x1080 and 2560x1440, and the Thunderbolt display at 2560x1440. It is not the case that a global menu bar is not ergonomic on large screens."
So global menus are ergonomical because Apple thinks so? Because Apple does things this way it doesn't mean that there isn't a problem with it.

I would love an Unity AppMenu (let's hope for a Compiz plugin!), but Manny's last proposition really is the most reasonable one for this cycle, and it could increase menu discoverability and its persistence.

I think this discussion gave us good solutions for two major problems with the global menu:
1- An option to turn global menus on/off for non-maximized windows/always off;
2- A fourth window button to turn menu persistence on/off, which could work both for maximized and non-maximized windows.

[Danillo (danillo)]

Fenryxo's code for the appmenu is here: http://bazaar.launchpad.net/~janousek.jiri/+junk/jjdesktop/files/head:/src/windecor/

According to him, it's written in Vala, but Unity Window Decorator is written in C,. Therefore, we would need someone to port it.

[Jānis Kangarooo (kangarooo)]

Now isnt human first but computer couse were forced to adapt not computer has adapted to us.
To make human is first and not computer to who i need to change myself to understand it then
LOGIC- one way always so
   [ ] Global Menu on
   [x] Global Menu off
   [ ] Global Menu only for maximized windows

Best solution
   [x] Netbook remix LTS 10,04

[Greg Merchan (gregory-merchan)]

I remembered another one.

5) The default mouse or trackpad acceleration settings may be bad.

@Romano: Click to focus is the only supported focus model in 11.10 (and older releases?). In the same sense as having a global menu bar isn't an option anymore, click to focus isn't an option either. You still have the option to change your system, but not in a way that is supported. Since you've already tweaked your system, you can tweak it to turn off the global menu bar, or perhaps try something like what was suggested here: http://brainstorm.ubuntu.com/idea/27724/

[Graham Hawkins (grahamhawkins)]

"Click to focus is the only supported focus model in 11.10 (and older releases?). In the same sense as having a global menu bar isn't an option anymore, click to focus isn't an option either."

I've use focus follows mouse and autoraise for about 20 years, and I'll go to some lengths to configure my system so as to be able continue to use it...

Global menus don't sit well with such a configuration - so to be able to configure them off (or limited) would be good. And I also quite Manny's suggestion of #106.

More generally (and probably off topic) I somewhat lament the trend towards non-configurability in today's desktops. They look pretty, and work to the design team's vision of how a desktop should be, but not all users share that vision in all respects. I suppose I should write my own to suit myself, but really, all I want to do is edit a config file to make the desktop comfortable for me, and get on with my work.. </rant>

[Romano Giannetti (romano-giannetti)]

@Graham: 100% agree with you.

By the way, apart for the global menu, focus-follow-mouse works ok with unity --- why limit a working functionality used by quite a number of users?

[Graham Hawkins (grahamhawkins)]

@Romano
Yes - Unity does indeed work quite nicely with focus-follows-mouse and auto-raise. I've also removed the packages that implement global menu, and turned off screen-edge window maximisation. And I'm reasonably happy with the result.

It's just that I'd have preferred to have a GUI (or maybe a file) to configure these items in one rather than having to jump through hoops to do it...

[Pedro Bessa (pedbessa)]

The M button is too small. In the Firefox app button, there was New Tab >. People had to click > to open the menu, but people had trouble targetting the mouse pointer to the >, so the firefox developers made the menu open after a while hovering New Tab >. That makes the surface area be New Tab > instead of just >. Please, make the M button be Menu >. thx

[manny (estelar57)]

@pedro

The M button is for demonstration. The devs could use it because is small and non intrusive, but It could be changed to say "menu" or be the name of the app too, if they think is better.

However, you should note, that this is not the same as a "non persistent" dropdown menu button like firefox or opera.

As from the feedback in the comments, a horizontal, on-demand and persistent solution would work better for a number of apps (specially productivity), than the vertical kde appmenu. You toggle it when needed.

For predictability the global menu is also available, as suggested in comment #60 (which also has a patch that seems to implements about 60 or 70% of the design).

So this is half done and looks like is the current solution that has the most characteristics users were asking for.

[Romano Giannetti (romano-giannetti)]

@manny: yes, I think that solution in #60 is great, and solves most problems.

[manny (estelar57)]

so from #106 (which also includes #60) would be something like:

 [X] Global Menu on (for predictability)
 [X] Button toggles menu visibility in un-maximized windows

[Danillo (danillo)]

I think the button could toggle menu visibility in maximized windows too. This would increase discoverability of the global menu and allow to directly control its persistence.

[manny (estelar57)]

@Danillo

Down the road, if the devs see a necessity, it could also scale to toggle persistence in maximized too (per app). But this bug is to resolve the issue for unmaximized first, so that would probably be a later topic.

But for discoverability, is going to help that it will be shown for 2 seconds.

https://bugs.launchpad.net/ayatana-design/+bug/874254

[Pedro Bessa (pedbessa)]

'm going to see an unmaximized window, then a maximized window, then expect to find a button to toggle menu visibility in the maximized windows, but actually not find it in there, then file a bug report with steps to reproduce, expected results and actual results.

I want a button to toggle menu visibility in the maximized windows, because of consistency, so there are two advantages, consistency and discoverability now.

[manny (estelar57)]

The dash, the scrollbars, the launcher, greeter, etc. all are still evolving. So it can take a few cycles for some things to become feature complete.

[Pedro Bessa (pedbessa)]

If I could create an app that changed the global menu behavior and appearance, I would. If I could put the app in Ubuntu Software Center, I would.

Firefox lets programmers change all of Firefox's behavior and appearance. Firefox plays with the imagination of programmers, invites work from programmers, makes the Firefox platform cooler.

Just like that, Unity should let programmers change all of Unity's behavior and appearance too. Unity should play with the imagination of programmers, invite work from programmers and make the Unity platform cooler.

Do you agree with me?

FIrefox uses XML DOM with insertBefore, removeChild, setAttribute and CreateElement to position, remove, edit and add anything. I want XML DOM without Javascript if possible, because Javascript is for the web, for the browser and Unity is for the desktop, for the operating system.

[manny (estelar57)]

@pedro

i know you want this fixed like everyone here, but please try to keep things on topic.

[Romano Giannetti (romano-giannetti)]

I agree with manny: this issue is at a point where the only thing needed is code. I do not think that continuing pestering will help. Developers will be on holidays, too ;-)

[Pedro Bessa (pedbessa)]

since:
manny said the app button doesn't have to a small green icon, it can be a title
manny said the app button / title doesn't need to be clicked, it can be moused over

how about:
[x] in maximized windows, when I mouse over the title bar, the menu bar appears where the title bar was
[x] in non-maximized windows, when I mouse over the title bar, the menu bar appears below the title bar

[Michal Predotka (mpredotka)]

Looks like there will be setting to switch global menu off in the next Ubuntu version. Read more here: http://design.canonical.com/2012/01/system-settings-for-precise/ and look at this: http://tinyurl.com/7ffotax

[levu (levu)]

Come on, add support for "only for maximized windows" please...

thx!

[manny (estelar57)]

@pedro

actually i think you were confusing the various designs. The one in comment #106 is persistent on button click (button could be small windicator or app name, not the full titlebar itself). Mousing over the title bar could create false positives in this design. Mouse over is only good if its non persistent like on earlier suggestions, but that has it's own set of pros/cons. The persistent design seems to be the suggestion with less cons overall from most of the feed gathered.

@mmiicc (mpredotka)

I believe those are still mockups, but it gives hope ! :)

not sure which will be the final options yet. But it could be something like this:

[X] Menu always integrated in top bar (global menu On)
[X] Integrated with individual windows (global menu Off)
[X] Global menu On + Button can toggle menu visibility in individual windows (combo)

[Pedro Bessa (pedbessa)]

I worked on this global menu for six hours with only one meal break to give you this final comment!

In maximized windows, if you hover "<window title> - <app name>", the menus replace "<window title> - <app name>", so you can click a menu and so you can't drag-and-drop the window, because there's no space left in the screen to move the window.

In non-maximized windows, when you click "<window title> - <app name>", the window is highlighted (with outter line in strong yellow and inner content in light yellow, this is like compiz, when you're dragging-and-dropping windows), so you can hold the click down to drag-and-drop the window.

In non-maximized windows, when you hover "<window title> - <app name> <down arrow>" for a short while, the menus appear and persist below the title bar, the <down arrow> becomes an <up arrow> and when you hover "<window title> - <app name> <up arrow>" for a short while, the menus disappear and dispersist from below the title bar.

OK, so what do you say?

[alkatraz (hellion-bg)]

I totally agree with the idea for the options for the global menu.

 [ ] Global Menu on
 [ ] Global Menu off
 [x ] Global Menu only for maximized windows

[Giorgio Wicklein (giowck)]

With the new HUD plans, the global menu related issues will be temporary... maybe until 12.10

[Andrei Emeltchenko (andrei-emeltchenko-finik)]

 [ ] Global Menu on
 [ ] Global Menu off
 [x] Global Menu only for maximized windows

[Bug Reporter 11 (bugreporter11)]

> With the new HUD plans, the global menu related issues will be temporary...

Please explain. I do not see how HUD solves the bad mouse ergonomics described in this bug report.

HUD is a non-menu system, but it still presents a list of "menu items" (just don't call them that). And HUD is still disconnected and distanced from the window where one is working, just like the global menu. On large or multimonitor setups, the HUD will be a long way away at times.

Not only does one have to type to get the list to display some choices, picking one of those choices is often most conveniently done with the mouse -- just watch Ubuntu's own promo videos for HUD. Since I have 3 monitors, moving my mouse all the way to the upper left is not ergonomic.

The traditional design is still much better. Couple that with an ergonomic mouse, and you have a solution that is far better than Unity/HUD. (I use a Roller Mouse, so I can move the mouse cursor without reaching away from my keyboard.)

[tekstr1der (tekstr1der)]

It looks like fixing this problem is actually on the radar for 12.04 LTS. It's important to note that the fix _cannot_ simply be an ON/OFF option:

1) ON - Leaves alive all the same issues described in this lengthy bug report.
2) OFF - Defeats the benefits of the Global Menu with a maximized window.

While those two options should certainly be available, it is critical that the fix includes the single most important and most requested option:

[x] Global Menu only for maximized windows

Without this option, no progress toward a real solution will have been made. Having all three options will satisfy the full range of users and use-cases.

[Pedro Bessa (pedbessa)]

[x] Global Menu only for maximized windows

[Adolfo Jayme Barrientos (fitojb)]

See also http://ubuntuforums.org/showthread.php?p=11685718

[Tsvetko (tsvetko.tsvetkov-deactivatedaccount)]

What about the hidden window controls for maximized windows? Shouldn't there be also an option to disable the hiding since you've got a lot of space on a large screen.

[TomasHnyk (sup)]

Jack: that is bug 783240 . I hope someone has a look at it.

[Mark S (zarg-)]

I too would like:

 [ ] Global Menu on
 [ ] Global Menu off
 [x] Global Menu only for maximized windows

[Pedro Bessa (pedbessa)]

In Windows, the Firefox app button is on top left. Since titles vary in length and it's good to have the app button always in the same place, because it makes finding the app button easier, we would better have: close minimize maximize [app name] title.

[dstaubsauger (dickerstaubsauger)]

"fix commited" is not the appropriate status when you have a feature request for one feature and implement a different one. I'd still like to see an option for having global menu for maximzed windows and a normal menu (not lim where i have to click an extra button to open the menu) for the non-maximized windows.

[Daniel van Vugt (vanvugt)]

Fix committed into lp:compiz-core at revision 3036

[Alexey Kulik (doctor-rover)]

I agree that LIM is not a solution. As for me, I do not like the idea of LIM at all. Though, it may be an option, of course, for those who find it useful. But I do like global menu for maximized windows. And I would like to have a normal menu for non-maximized windows. So the initial suggestion for the three options (on - off - only maximized) seems to be the most comfortable and flexible solution.

[design_dolphin (designdolphin22)]

As much as I like the look of some of the beautiful work on Unity, and how well it runs at times, and the potential it has, I don't think it should be up to the window manager to determine how the menus of applications look. In all sincerity I believe there are too many different options possible, to for now, make one general layout. Some programs have 3 rows of buttons and menu's (Bluefish for example). It can also prove difficult to keep up with interface design in the future. Afraid this may be painting yourself into a corner.

A app button such as Firefox or Opera use, can possible be an option, but even then Firefox lets you choose how you want to dictate your button.

In conclusion I like the Gnome 3 interface better in that regard.

Also I find the whole shifting of the close, minimize buttons on the left side, underneath the application name confusing. I have given Unity a fair change, but when I have multiple apps open I find myself time and again getting lost and confused, as to what is where. I'm not sure if this is something that will grow on me, because I have to learn something new. In comparison I picked up the Gnome 3 interface up rather quickly, and it feels really intuitive.

I'm really wondering if this is not a waste of time and resources, and things should be concentrated on other things, or at least move Unity to a more experimental screen saver, and concentrate efforts on integrating Gnome 3 properly. Worst case scenario one can always fork that if not completely satisfied. Let's avoid building YAWM (Yet another window manager), that although it has promise, some really cool stuf, and beautiful design, it is too soon implement as such.

[manny (estelar57)]

While LIM is a great advancement to solving this bug, but some people don't seem convinced yet.

So from all the feedback from various discussions (here and on unity-design), I can only conclude that an alternative worth exploring could be something combined from these 2 proposals:

http://musl1m.deviantart.com/art/Windicators-well-sort-of-203350326

https://bugs.launchpad.net/unity/+bug/682788/comments/106

Is still local and integrated, so it might be called "LIM2".

to be fair and not a biased decision, a poll would be nice to see which one users prefer: prototype LIM1 or prototype LIM2.

[Romano Giannetti (romano-giannetti)]

I still think that the optional "use global menu only for maximized windows" is still cleaner, easier and consistent. Nevertheless, i do not dislike LIM1.
Not so sure because in the meantime I switched to Gnome Shell. Will try again Unity on Pangolin upgrade.

[Joschi Poschi (joschiposchi)]

Wouldn't it be possible to have the appmenu

1) in the panel for maximized windows
2) in the window title bar for non-maximized windows

So this would mean the menu would always be next to the close buttons (consistence), monitor space usage is reduced (for smaller laptops) and the menu stays with the associated window (consistence).

[Pedro Bessa (pedbessa)]

I loved the windicator icon size, because it's an arrow inside an ellipse and it's a wide icon, so I won't have to strive to target the mouse pointer to the icon.

Combining lim1 and lim2, put the green icon's m inside the windicator icon's ellipse and use the green icon functionality in the ellipse with m.

[Pedro Bessa (pedbessa)]

We're 13 days away from Ubuntu April, 2012.

Here, greeks and trojans argued a lot. Some want global menu for maximized windows only, others want app buttons instead of menu bars. I don't think the Ubuntu team be able to please greeks and trojans.

What's decided by the end of this hot bug report?

[dstaubsauger (dickerstaubsauger)]

To me and all the others commenting here: I think they don't even read this any more. Did you for example notice those status changes between #159 and #160? They're simply following some design agenda and started tracking that agenda's progress in this launchpad entry at some point.

[Gabriel Mazetto (brodock)]

I really liked #160 sollution, but I would change that icon to something more like the "shelf" icon on Mac or a "menu-like icon" similar to the one of LIM (without the triangle symbol inside).

Also to give the idea of "toggling", the "bubble" of the icon could look like "pressed" when activated (when the menu is visible) and look like as an unpressed button when disabled (not visible)

[Pedro Bessa (pedbessa)]

I'm sorry for my bad behavior here. I won't send correction messages after sending a message any longer. I'll try to get the only message right.

[Launchpad Janitor (janitor)]

This bug was fixed in the package compiz - 1:0.9.7.2-0ubuntu1

---------------
compiz (1:0.9.7.2-0ubuntu1) precise-proposed; urgency=low

  [ Łukasz 'sil2100' Zemczak ]
  * New upstream snapshot:
    - Fix global menu not being ergonomical on large screens (LP: #682788)
    - Fix Alt+Right arrow key (LP: #943612)
    - Fix key bindings for actions while doing tap detection (LP: #944631)
    - Window movement is erratic and buggy, backport (LP: #923683)
    - CompScreenImpl::addAction(CompAction*): Assertion `priv->initialized'
      failed (LP: #946118)
    - gtk-window-decorator crash with SIGSEGV in max_window_name_width()
      (LP: #937815)
    - Finish the implementation of the locally integrated menubars
      (LP: #931245)
    - Unity/compiz intercepts keystrokes from grabbed windows (LP: #806255)
    - Pressing alt doesn't show the menu title bar in top panel (LP: #943194)
    - Fix Alt stealing focus from widgets (LP: #943851)
    - Fix Alt + drag (LP: #945373)
    - lp:compiz-core fails parallel builds (make -jN) (LP: #938417)
    - Changing the HUD shortcut disables all Alt-based combinations. And
      changing the Dash shortcut disables all Super-based shortcuts
      (LP: #945816)
    - Fix key bindings (such as Super) not working on empty workspace or on
      slow/loaded systems (LP: #953089)
    - compiz crashed with signal 5 in Glib::exception_handlers_invoke()
      (LP: #808007)
    - Fix segfault caused by r3043 (LP: #958540)
  * Removed cherry-picked patches:
    - debian/patches/fix_806255.patch
    - debian/patches/fix_923683.patch
    - debian/patches/fix_943194.patch
    - debian/patches/fix_944631.patch
    - debian/patches/fix_alt_pressing.patch
    - debian/patches/additional_alt_tapping_fix.patch

  [ Didier Roche ]
  * pick upstream fix, debian/patches/fix_953839.patch:
    [regression] Invisible resize border is now only 1px wide (LP: #953839)
  * debian/patches/revert_lim.patch:
    - revert the integrated menu patch. It won't be released in precise and
      triggers a regression (in bug #962085)
  * debian/patches/fix_953089_2.patch:
    - second trial to fix remaining corner cases
  * debian/patches/exit_1_if_composite_cant_init.patch:
    - try to workaround a crasher which seems to happen when the composite
      plugin failed to initialize. Hopefully exiting 1 will make gnome-session
      respawning compiz and then the init will work. (LP: #833729)
  * debian/patches/always_replace.patch:
    - right now, always replace the current WM as it seems that some people
      got another compositor running at the start of the session. This will
      hopefully workaround the issue that some people experience.
 -- Didier Roche <email address hidden> Fri, 23 Mar 2012 09:13:51 +0100

[Shiba (shiba89)]

Could someone tell me how was this fixed? Maybe because my max resolution is of 1280x1024, I cannot see any difference. Just asking out of curiosity.

[Nicolas Delvaux (malizor)]

AFAIK, this bug was not fixed.
Just read the changelog:

- Finish the implementation of the locally integrated menubars
[...]
- revert the integrated menu patch. It won't be released in precise and triggers a regression (in bug #962085)

[Heimen Stoffels (vistaus)]

Indeed. It was reverted back. Please change the state of this bug back to Confirmed/Wishlist.

[Daniel van Vugt (vanvugt)]

Code removed in lp:compiz-core at revision 3077

[Pedro Bessa (pedbessa)]

12.04 is near. The LIM Button can't be made until 12.04, but the global menu for maximized windows only can. These features are evolving, anyway. What if we have the global menu for maximized windows only in 12.04 and the LIM Button in 12.10?

[John Lea (johnlea)]

Description updated

[TomasHnyk (sup)]

John: it is not clear from you updated description whether it will be possible to use global menus for maximized windows but not for unmaximized (at the same time)?

[John Lea (johnlea)]

@TomasHnyk; yes it will be possible a window to have it's menu integrated into the top bar only when it is maximised ;-)

[John Lea (johnlea)]

for ^

[Varun Priolkar (varunpr97)]

The problem should be solved by Locally Integrated Mienus which will arrive in 12.10...

[Roshan (rospkos-07)]

For 12.10 the LIM is dynamic ie.. for unmaximized windows LIM icon is present and for maximized ones, the LIM is absent and the global menu takes over.

The placemnt of LIM icon should be little far(about 6-8 mm) from the windows control buttons(close/minimize/maximize) and clear to the windows title(2-3 mm). The menu is displayed through a hover trigger over the icon.

[Roshan (rospkos-07)]

A slight suggestion to the hover trigeer is the a light low timeout preferably about one and a half second should be added.

[Danillo (danillo)]

Roshan, LIM is going to work in a little bit different way than that: https://lists.launchpad.net/unity-design/msg08710.html

[Roshan (rospkos-07)]

> Roshan, LIM is going to work in a little bit different way than that:
> https://lists.launchpad.net/unity-design/msg08710.html
>

@ Danillo: LIM is yet to be in actual code. Now i have a thought on HUD. it
is the future right out. LIM may be evolved a bit in the future release.
The only way to get LIM code right is through testing with various mouse
actions like whether it affect window grabbing, etc.

[John Lea (johnlea)]

Note: Menu feedback has been taken into consideration, and a set of menu improvements are planned as part of the 12.10 'Enhanced Menu' project (see bug description). This bug is already being used for tracking the status of this project, so I am rolling all the bugs that will be fixed by 'Enhanced Menu' project into this single bug.

[Joshua Dunamis (dunamis)]

I vote for
 [x] Global Menu on
 [x] Global Menu off
 [x ] Global Menu only for maximized windows

I think is ok the switch on/off of global-menu (if this is the user's will) but the third solution is really more ergonomical and a more intelligent choice.

[Joschi Poschi (joschiposchi)]

As I have asked before: Isn't it possible to put the global menu into the "window decoration/caption bar" for non-maximized windows?
So it would always be in the bar above the window. Nice, clean, logical and consistent.

Otherwise I'm with the
[x] Global Menu only for maximized windows
solution.

[LiohMoeller (liohmoeller)]

I would also like to see an option like

'Do not hide Global Menu'.

Right now, the global menu and the action buttons are hidden after a definable time. I would prefer if they would be visible all the time as e.g. on Mac OS X. Hiding it might lower clutter but sadly it lowers productivity, too as I have to 'guess' where a menu entry is before I actually see it.

[Hlobil Vaclav (vaclav-hlobil)]

Current status (always global and hidding menu) is absolutely user UNfriendly.
So my opinion is:

[x] Global Menu only for maximized windows
[x] Do not hide Global Menu

And it'll be perfect. All should be optional, but these as default.

[Chris Richards (9e9o1ko8b2f5xpiibg-chris)]

Please, oh Ubuntu gods, allow the Global application menu to always be visible!

There's nothing worse than having to move your mouse around to discover what might be or might not be there. It takes all the snappiness out of the interface.

This fading menu is a terrible idea! It means I have to continuosly hover my mouse over the top bar to see what the options are. How is this good?

Even when I can remember what the menu options are, I still have to first move my mouse to the top and then move accross to the exact location of the menu item. It really slows my workflow down. Please fix it!

The Unity interface is so nearly great!. it just has a few massive usability issues that stop it from being great. Like this one and also the fact that a large number of applications don't appear on the Alt-Tab menu even when they are running.

Who is making these UI decisions? developers? Why do you think apple don't have fading menus?

[Chris Richards (9e9o1ko8b2f5xpiibg-chris)]

One reason "use global menu only for maximized windows" is a bad idea because you shouldn't be trying to encourage people to be maximising windows. The reason we have larger screens is so we can fit more than one window on the screen at any one time, I usually have several. Microsoft Windows users are the main culprits of the "maximize everything" culture and this is not something anyone should be aiming for.

What OSX does with it's permanent menus actually works well and I've never heard any complaints about it. Everyone who has been forced to use Unity at the company I work for has complained about this particular aspect of it. The solution is easy, just enable always visible Global Menus, or at-least allow us the option to enable then.

[Sebastien Bacher (seb128)]

@Chris:

> This fading menu is a terrible idea! It means I have to continuosly hover my mouse over the top bar to see what the options are. How is this good?

Well, you seem to be an heavy menu user, most users are not (if you use a web browser, an email client and a text editor most of the common functions are in the toolbars for example). Quite some users like the visual improvement and the clutter reduction which goes with hidding the menus. That said adding an option to not hide the menus was planned for precise but didn't get worked in time, it's like to happen next cycle though

>Like this one and also the fact that a large number of applications don't appear on the Alt-Tab menu even when they are running.

That seems to be bugs rather than any design decision, you should open bugs when you run into such cases

[Ingo Gerth (igerth)]

> Even when I can remember what the menu options are, I still have to first move my mouse to the top and then move accross to the exact location of the menu item.

This is a perfect use case fur the HUD. Press alt.

[Dag Ågren (paracelsus)]

I have found that sometimes icons in the sidebar are mysteriously coalesced. For instance, I've had Chrome and gedit merge into a single icon, and clicking it would bring up the windows for both. However, this happens too seldom to be reproducible, and I am not sure it has happened in 12.04 yet, so I have no idea if it has been fixed yet.

But that is fairly offtopic for this bug.

For this, I agree: Hiding the menu is TERRIBLE for usability. Please don't fall into the trap of trying to reduce "clutter" by sacrificing usability. "Clutter" is NOT always a problem that needs to be fixed. Sometimes you really do need it. There is a reason the menu bar is always visible on Mac OS X. Apple does put a lot of effort into usability.

Hiding it destroys most of the benefits of a global menu bar, rendering it mostly useless. The fact that you can no longer aim at the entry you need is a serious problem with this design.

[Fabien Lusseau (fabien-beosfrance)]

@Chris: We can also argue that having a global menu for anything make the user maximize because this user don't want to move his mouse all over his desk to only reveal a menu ...

I know I feel this problem, and I maximize nothing. Having this option (use global menu only for maximized windows) will actually make my desktop more efficient for unmaximized windows ...

I don't know why you are thinking the opposite, I think "use global menu only for maximized windows" will not do anything about your "fear" of ... of what actually ?!

I mean come on ! It's not like someone will change all his behaviors depending on (on large screens) 2% more wasted space.

And even me, that is extremely annoyed by theses recurring search of the missing menu have not changed my behaviors at all in that matter.

[Aaron C. de Bruyn (darkpixel2k)]

I can't stand the global menu. I've switched away from unity as a result.
As a developer, I constantly have a bunch of 'layers' of windows open.

For example, I might have a terminal window open in the background, my IDE over top of that, and finally my web browser for testing the site I'm developing.

Now I refreshed a page on the website and I want to see my terminal in the background (instead of my IDE) to see some output...except I can't just minimize the IDE like I could with previous versions of Ubuntu--because there is no minimize button until I click on my IDE and then move the mouse all the way up to the top-right corner of the screen.

Unity totally interrupts my workflow with the global menu and also the screwed up ALT+TAB order and behavior and all the shortcut keys its taken over. The whole 'lens' idea is awesome though--why wasn't it simply added to Gnome2/3?

[Chris Richards (9e9o1ko8b2f5xpiibg-chris)]

Ok, Why don't you extend this philosophy by only showing the window that the users mouse is currently over? This will reduce clutter even more! Great plan eh?

[Andrei Emeltchenko (andrei-emeltchenko-finik)]

I think what happened is that designers copied Apple concept but unfortunately made some modifications :-(. Please if copy, then copy exactly!!

[Chris Richards (9e9o1ko8b2f5xpiibg-chris)]

> This is a perfect use case fur the HUD. Press alt.

No, the HUD is only good when you know exactly what command you want to run , i.e. you're an experienced user, and then only if the application supports it.

The menu should always be visible for reasons of dicsoverability and usability. How can anyone know that a menu is even there if you don't show it? Some applications have one and some don't.

> We can also argue that having a global menu for anything make the user maximize because this user don't want to move his mouse all over his desk to only reveal a menu ...

Move his mouse all over his desk? I have a very high resolution monitor and it takes about 0.2 seconds, and about 1-2cm of mouse movement, to move my mouse from the bottom corner to the top corner of the screen. I am using Ubuntu 12 with the default mouse sensitivity settings. A new user won't mind moving his mouse that 1-2cm. An very experienced user will use the HUD or other shortcuts. Surely the aim is to make users comfortable enough with applications until they can only use the HUD or shortcuts? Reducing clutter is a nice goal but you should never sacrifice usability to get there.

[Rachel Greenham (rachel-strangenoises)]

On 5/22/12 11:37 AM, Andrei Emeltchenko wrote:
> I think what happened is that designers copied Apple concept but
> unfortunately made some modifications :-(. Please if copy, then copy
> exactly!!
>
Well, except that they did *one* thing better than apple: In a
multi-monitor setup the global menu is on the same screen as the window
to which it relates. That's brilliant. (disclaimer: i haven't put a
second monitor on my linux box since before my upgrade to precise, so I
hope they haven't destroyed that functionality while I wasn't looking)

Really, guys, all we want is the damn menu for the active window to stay
visible. You probably want to position it to the right of the
application name rather than fading over the top of it (is that why
there's such resistance to making this change?)

[Romano Giannetti (romano-giannetti)]

As ever, all the last discussion is forgetting the user (like myself) which likes to have several windows on a big screen AND focus follow mouse. Global menu and focus follow mouse is a no-no unless the window is maximized.
Not all devices are tablet, not every user use their desktop as a big tablet.

[psypher (psypher246)]

I suggested the exact same thing due to this other bug:
"New windows are moved to front but don't take focus"
https://bugs.launchpad.net/ubuntu/+source/unity/+bug/781931/comments/31

TOO MUCH CLICKING!

Apps and menus should follow mouse over focus. Will fix many issues.

I use fullscreen apps a lot. This is how I would prefer it:

Default:
Fullscreen apps should always show global menus. Do not hide.
Minimized apps should have the menus locally integrated, less distance to travel to get to menu!

Optional:
Hide global menus
non-locally integrated menus on minimized apps
The highest foreground app must by default grab focus
Any app you move your mouse over must get "Menu" focus, don't bring to foreground though! interacting with the focused app will bring it to foreground, like keyboard input.

Love unity and all the features. But the focus and global menu thing is a bit annoying. Some refinement needed.

[Marius B. Kotsbak (mariusko)]

Romano: these hidden interface elements (menu+window controls) actually does not work on tablet devices without mouse, as it is not possible to move the mouse pointer without clicking.

For netbook devices with mouse and small screen the current behavior could be the best (but should be a user choice). On my device, there is not enough space for menu+indicators+window controls. Maybe the menu should have been below the other things.

[Rachel Greenham (rachel-strangenoises)]

If these comments reveal anything it's that different people want to
work in different ways. Those of us whose other main machines are Macs
want a permanently visible global menu; those whose other machines are
Windows, or just came from earlier versions of Gnome, want menus
attached to the windows, and a variety of other options - wow, people
still do focus-follows-mouse? :-P

TBH I think most of the problem here has been the recent-years fetish
with removing user preferences for this stuff; that's what makes the
decision to go with the "wrong" paradigm as default a major PITA for
already-competent users rather than a minor annoyance that's fixed
within a minute or two of first logging into a new system.

Choose whatever default behaviour you want for the new-to-ubuntu user;
but give the rest of us *choices*!

It's good to see that seems to be the way the current thinking is
leading; I just hope we all get the choices we want. :-)

[Romano Giannetti (romano-giannetti)]

@Rachel: +1. No, wait, +100.

[Ingo Gerth (igerth)]

===========================================
STOP POSTING YOUR OPINION AS COMMENTS HERE
===========================================

Dear all,

please remember this is a bug report and you should only post comments related to the technical problem here.
If you want to share your opinion that's great, but please do that on the Ayatana Design mailing list.

Everytime you post here thousands of people receive your comment via e-mail and can get annoyed, so please consider before posting here.

Thanks, Ingo

[Chris Richards (9e9o1ko8b2f5xpiibg-chris)]

> those whose other machines are Windows, or just came from earlier versions of Gnome, want menus
attached to the windows,

I've come from Gnome & Windows and I've never used a Mac. I'm quite open to the Mac way of doing things, just aslong as it's done correctly with menus that are always visible.

[papukaija (papukaija)]

@uday: Please don't change this bug without explanation.

@Ingo: Posting to Aytana mailing lists is waste of time as community engagement is broken (see bug 882274).

[Aleve Sicofante (sicofante)]

Just tested Quantal's daily build and there doesn't seem to be any changes from Precise. Will this be ready for feature freeze?

I checked at Settings->Appearance->Behavior, maybe the configuration is somewhere else?

[Pedro Bessa (pedbessa)]

Do the following instructions work in your computers?
http://www.ubuntuvibes.com/2012/03/how-to-install-new-locally-integrated.html

[Aleve Sicofante (sicofante)]

Thanks, but I'm expecting global menu options, not the LIM. you know:

[x] Global Menu on
[x] Global Menu off
[x] Global Menu only for maximized windows

We had been promised some of this would land on Precise. I understand it couldn't make it, but hoped it would be in Quantal.

Can any Ubuntu developer please chime in and give us an idea of what's the status of this and if we can expect any of those options to be available in Quantal?

[Ingo Gerth (igerth)]

Why do you not want to inform us about the status of this project? Is it necessary to be secretive about this? Asking since you removed the line

" - More details to follow during the 12.10 cycle... ;-)"

If it won't make it into 12.10 that's fine, but many users would appreciate it if you would just say that then.

[yman (s-y-schwarz)]

The App Menu should be in the Title Bar. When the window is maximized the Title Bar is merged with the panel so the App Menu would naturally be merged with the panel.

[Pedro Bessa (pedbessa)]

Development stopped, because there are lots of ***disagreements*** between us all.

There were three alternatives.
[] global menu on
[] global menu off
[] global menu only on maximized windows
We came up with new alternatives.
[] mockup 1
[] mockup 2
[] LIM

we need to:
- vote on the new alternatives / mockups until 100 votes
- count votes
- ***decide*** the lead alternative

The Ubuntu Community must pressure the Ubuntu team a lot to get the lead alternative implemented.

By the way, here is my vote:

[x] LIM

[Marius B. Kotsbak (mariusko)]

Disagreement can be solved by having configuration options. Only the default must be agreed upon (or decided by Canonical). If even that is hard, the user could be asked at first login.

[Nekhelesh Ramananthan (nik90)]

What I do not understand is that the official design decision has been made by the Ayatana team (John Lea). So I do not see why the disagreements should stop the development. Besides can't the final decision be made after user testing this like in other situations?

[Andrei Emeltchenko (andrei-emeltchenko-finik)]

Oh shit, how this simple issue might be so complex? Please provide a way to have local menus for apps like terminals and stop copycat Apple shitty approaches.

[Aleve Sicofante (sicofante)]

2012/9/13 Pedro Bessa <email address hidden>

> Development stopped, because there are lots of ***disagreements***
> between us all.
>
> There were three alternatives.
> [] global menu on
> [] global menu off
> [] global menu only on maximized windows
> We came up with new alternatives.
> [] mockup 1
> [] mockup 2
> [] LIM
>
> we need to:
> - vote on the new alternatives / mockups until 100 votes
> - count votes
> - ***decide*** the lead alternative
>
> The Ubuntu Community must pressure the Ubuntu team a lot to get the lead
> alternative implemented.
>
> By the way, here is my vote:
>
> [x] LIM
>
>
1. Where are the mockups 1 and 2?
2. Where do we vote?

[Pedro Bessa (pedbessa)]

[] mockup 1 -> http://imageshack.us/f/837/screenshotdesktop.png/ and http://www.webupd8.org/2011/02/unity-mockup-menu-integrated-in-window.html
[] mockup 2 -> http://www.webupd8.org/2011/02/unity-mockup-menu-integrated-in-window.html and http://anaershadowynomaly.deviantart.com/gallery/29691776 http://anaershadowynomaly.deviantart.com/gallery/29691776#/d3dygwc
[] LIM -> http://www.webupd8.org/2011/11/oxygen-appmenu-replace-menu-with.html http://minus.com/lbq3ka2PRj4EKV and http://madjunir.deviantart.com/art/ubuntu-menu-button-un-maximized-windows-273062518 https://lists.launchpad.net/unity-design/msg08710.html

to vote for LIM, write [x] LIM, then click Post Comment

we need a decision

[Nate Wiebe (natew)]

[x] LIM all the way

[Joschi Poschi (joschiposchi)]

[x] mockup 2

[Doug McMahon (mc3man)]

@ Pedro Bessa
Do you have anything to back up "Development stopped .." other than YOU just stating that?

[TomasHnyk (sup)]

Voting is useless, I do not think this is how Ubuntu developement works. Also, if you read the bug description, the solution has been decided already (LIM, whatever you think about it).

[Ingo Gerth (igerth)]

Pedro, are you a developer? If not who is your source?

Look at how much attention this bug has. The ridiculous part is how the Canonical developers handle this whole situation, it is really a public relations and community involvement disaster.

First they promise that they will integrate LIMs. Then there is silence for a while, but everybody is expecting something. Then there is even more silence, and no response whatsoever.
If the feature gets delayed that is okay. But then they should say so, since people are looking forward to this feature (and others!) and have high hopes.

The developers really should become a bit more open towards the community. People will step back from involvement if treated like this.

[Marco Biscaro (marcobiscaro2112)]

Please, this is not a poll system, its a bug tracker. The decision was already taken (see bug description).

[Pedro Bessa (pedbessa)]

@ Doug
no

@Ingo
I don't have a source.

:-(

[Aleve Sicofante (sicofante)]

I'm really confused. LIM and those two mockups have NOTHING to do with how the global menu behaves or the original description of the Enhanced Menu project (described in the "Desired change" section of the description). How is it a solution to the VERY SERIOUS ISSUE that the global menu hides, making it hard to understand and use? (Three hours on the phone with my very old mum yesterday, trying to make her understand that there was a menu at the top and that he had to go up there to close the window too).

LIM and other integrated menus tackle a completely different issue, that is PART of the problem (menus global or not) but not the other part of the problem (global menu hidden or a la OS X).

Shuttleworth (and if I'm not mistaken John Lea as well) were describing a solution that included a permanently visible menu many months ago. What happened to that? Will the only solution be the Unity-Revamped third party collection of patches? (Thanks Isaac!!!!)

Please Mr. Lea or Mr. Shuttleworth, be so kind to chime in and clear this up. I just don't understand the silence.

[Kenny Woo (hkenneth)]

Why is solving this issue so hard? Why cannot the developer give user configuration options?

JUST GIVE US AN OPTION TO SHOW THE DAMN GLOBAL MENU ALL THE TIME!

Novice Designer Mistakes

Changing shit for the sake of changing it.
Hiding necessary elements for a "minimalist" look aka sacrificing usability for looks.
Failing to understand that a cohesive design and user experience is more important than a group of diverse customized designs and experiences clumped together.
Falling in love with your design and not letting anyone experience it in a way that is different from your vision (aka customizing it)

[Rachel Greenham (rachel-strangenoises)]

[x] option to show the damn global menu all the time

i believe that was the original complaint here; recently there's been all these other options thrown in like someone *wanted* to muddy the issue. LIM fwiw is a cute variation on the theme of having the menu on the window, but which is just going to introduce more difficult design decisions that kicks everything further down the road (what to do about important window-title text especially if there's a no-autohide option, what to do when the window gets narrower than the menu...) to which the answers are going to be, in short, complex behaviour and clutter.

We just wanted the menu to not auto-hide. How can that be taking *years*? Time is not silencing the argument here!

And there's little point in repeating this isn't a place to vote when there *isn't* a place to vote. So we'll continue to say it here, so it's recorded, somewhere.

[Rachel Greenham (rachel-strangenoises)]

fwiw i'd also say that for consistency's sake leave the default as-is - not least for the reviews, where you'd have a choice between "They changed the way menus work *again*" and "While the default menu behaviour remains the same as before, there are now some user-configurable options to answer long-held criticisms."

[manny (estelar57)]

Woo there Kenny !! don't go bunkers! they are working on that and should land soon. :)

[Aleve Sicofante (sicofante)]

@Rachel Greenham: I couldn't agree more with you. We need to solve one single issue first: show the global menu all the time, then proceed with caution for any other options.

Just a few comments/suggestion on the main and secondary issues:

- Showing global menu permanently will hide the title of the window. I'd suggest it to be shown whenever the mouse goes to the top of the screen anywhere where there's no menu: for instance, the top-left corner. Throwing the mouse there will do two things: show the title and position the mouse over the close-window button. But throwing the mouse to the top of the screen to the right of the menu (maybe including the indicators area), will reveal the window title.

Regarding LIMs:

> what to do about important window-title text especially if there's a no-autohide option

- A similar aproach to what I suggested above: reveal the window title whenever the mouse is over non-menu areas (and of course by pushing a certain key, such as Shift, Ctrl, Alt, etc.)

> what to do when the window gets narrower than the menu...

- Whatever has been done for 20+ years with the classic menu bar in the window. This is not a new problem.

The problem I can see arising with menus on the title-bar is how to grab the window for moving it around.

But AGAIN: the primary concern NOW is having the global menu permanently visible. It's a serious usability issue that needs urgent attention.

[Rachel Greenham (rachel-strangenoises)]

On 15/09/2012 22:06, Aleve Sicofante wrote:

what to do when the window gets narrower than the menu...

> - Whatever has been done for 20+ years with the classic menu bar in the
> window. This is not a new problem.

i think they word-wrap onto additional lines, on windows at least.
that's going to be pretty in the titlebar!

But we're way off-topic with that here...

--
Rachel

[Pedro Bessa (pedbessa)]

+1 Rachel

Unity users want different things here. Beyond, I think Unity developers want different things here too, because Ayatana Design has Fix Committed, but it can't get the other projects to have Fix Committed too, so it looks like the other projects are disagreeing with Ayatana Design.

Gnome Shell has https://extensions.gnome.org/ An extension ecosystem is gold. Gnome Shell doesn't realize it has gold, so isn't shipped with extension support and doesn't make the extension support package visible. The Gnome Shell extension ecosystem was created and published by Gnome Shell community developers.

I remember a rich friend saying in Russia, people had one shoe size for all. People would go to Ubuntu Software Center, click Ubuntu Extensions, view global menu options and click install in the same row or view LIM in a row and click Install in the same row. You wouldn't have to worry about giving us one shoe size.

What do you think?

[Aleve Sicofante (sicofante)]

What I find appaling here is that we're a few days away from 12.10's release and not a single developer has had the courtesy of explaning to the 614 people affected by this bug what's being done (or not done) about it.

[Pedro Bessa (pedbessa)]

You mouse over the title bar, the url bar appears.
You mouse out of the title and url bar, the url bar disappears.
by Mozilla Labs
at https://addons.mozilla.org/pt-BR/firefox/addon/prospector-lessChrome-HD/?src=search

You mouse over the title bar, the menu bar appears.
You mouse out of the title and menu bar, the menu bar disappears.
like Mozilla Labs
What do you say?

[Andrei Emeltchenko (andrei-emeltchenko-finik)]

Whatever clever magic gestures you invent please give option to disable them.

[Pedro Bessa (pedbessa)]

The worry:
When a title is on the middle of the screen, your pointer is above the title, you want to click a thing slightly below the title and you move the pointer from above the title to slightly below the title, the menu bar appears on top of the thing and you click a menu item instead of the thing.

The relief:
Firefox has an app button. To use it, disable the Global Menu Bar Integration add-on, restart Firefox, right-click the Home icon, deselect Menu Bar. In the Firefox app button, menu items display sub-menu on a slightly delayed hover.
https://bugzilla.mozilla.org/show_bug.cgi?id=589146

You mouse over the title bar, after a slight delay, the menu bar appears.
You mouse out of the title and menu bars, after a slight delay, the menu bar disappears.
What do you say?

[Pedro Bessa (pedbessa)]

When the app opens, show the menu bar for a few seconds, then hide it.
Warning: the menu bar floats above the app content, because they're layers.

for consistency: window controls are always visible and appear by the left of the title in non-maximized windows, so they should be always visible and appear there too in maximized windows

for discoverability: google mobile is going to use three horizontal lines to represent a list and shows the Google service and product list when clicked, so instead of showing the menu bar for a few seconds, then hiding it, we could use an yellow icon with three vertical lines inside a circle by the right of the window title that represents a list and shows the menu bar when hovered or touched

(These two wishes are very good for tablets, because we don't keep track of the user's finger position in the air, so the user won't hover anything, so the user will see the icon and intentionally touch it.)

Agreed?

[Aleve Sicofante (sicofante)]

@Pedro: no offense but I'd say new designs are not the issue here. It was pretty much established months ago. We're just waiting for implementation and some voice from the devs camp to explain what's going on. What's stopping them from implementing and publishing the fix.

I think your proposals might be worth a discussion at the Ayatana mailing list, though.

[Pedro Bessa (pedbessa)]

CONGRATULATIONS, MR. MACKEY!

I'm a programmer and I tried to solve the problem, but I had to finish learning C and C++, and learn GTK+, Nux, Compiz and OpenGL, but when I thought I had to learn Nux and Compiz from their source codes, because I couldn't find their documentations, I got scared and gave up solving the problem, so I congratulate you for knowing C, C++, GTK+, Nux, Compiz and OpenGL, and solving the problem.

[Aleve Sicofante (sicofante)]

2012/10/20 Kamran Mackey <email address hidden>

> Fixed the issue, You can check for updates using the Software Updater to
> update your software.To manage notifications about this bug go to:
> https://bugs.launchpad.net/ayatana-design/+bug/682788/+subscriptions
>

Thanks for your effort but I just updated my system and can't find the fix.

Where do we find the interface to the fix after updating? I was expecting
changes in the Settings->Appearance section as per this draft:
http://www.muktware.com/3578/ubuntus-new-enhanced-menu-project, but there's
nothing like that in my just-updated system. I'm on 12.04.1

Can you please explain how this works and for which Ubuntu versions? If
it's only for 12.10 right now, can you please let us know if we can expect
it to be fixed for 12.04.2 too?

[papukaija (papukaija)]

@all: This bug is NOT fixed. If this bug was really fixed, it would have been announced by Ubuntu news websites and here by a developer.

@Kamran: since this bug is NOT fixed, please do not change the statuses or assignees of this bug. Thanks in advance.

@bug-control: Could you please revert these changes:? Thanks in advance.

Changed in unity:
status: Triaged → In Progress

Changed in ayatana-design:
status: Fix Committed → Fix Released

Changed in: ayatana-design
     Assignee: John Lea (johnlea) → (unassigned)

[Andrea Corbellini (andrea.corbellini)]

@papukaija: the Ubuntu bugcontrol team cannot revert such changes because they were made to projects, not to Ubuntu packages. However I have already contacted who can revert the changes; let's wait till Monday, if I do not get a response, I'll use the mailing list.

[John Lea (johnlea)]

@papukaija; thanks for resetting the statuses, I have updated the ayatana-design to the correct status and assignment.

@All; status and assignment in ayatana-design should only be changed by the Ubuntu design team or the Canonical QA team, please do not change the status here if you are not part of either of these teams.

[Pedro Bessa (deltrem1984)]

manny,

you wanted title bar click to toggle the menu bar. If people didn't want it, you said you would accept title bar hover to toggle the menu bar. I'm going to go with you! :-) I want title bar hover to toggle the menu bar.

Soon, I want:
- when the app is launched, the menu bar must appear for three seconds, then disappear for discoverability
- instead of toggle, unless it's needed (
install mozilla labs' lesschrome hd, hover tab bar, hover page content *
)
- instead of hover, slightly delayed hover (
turn off global menu bar integration, restart fx, turn off menu bar, click app button, slightly delayed hover a menu item **
)

Later, if all this works, I want:
- not only the menu bar, all bars under the title bar
- not only all bars under the title bar, window controls

* https://addons.mozilla.org/pt-BR/firefox/addon/prospector-lessChrome-HD/
** https://bugzilla.mozilla.org/show_bug.cgi?id=589146

replyyyyy

[Kay (ksthiele)]

 [ ] Global Menu on
 [ ] Global Menu off
 [x] Global Menu only for maximized windows

[[e-mail] (vaskostopoulos)]

put the Global Menu also in unmaximized windows

[Andrei Emeltchenko (andrei-emeltchenko-finik)]

I think we can establish a vote about that.

[Aleve Sicofante (sicofante)]

Guys: stop discussing the implementation. The design team and the Ayatana team have all the briefing and are working on this.

There's only one question remaining: WHEN?

This bug was to be solved for 12.04, then 12.10... Mark Shuttleworth promised well before 12.04 that the default menu behaviour would be tweakable in the direction this bug shows. I think it's not unfair to ask for a solid commitment from the devs about the chance of this bug being solved for 13.04.

So please Mr. John Lea et al: let us know how's this going and what our reasonable expectactions can be.

[Mark Shuttleworth (sabdfl)]

It will get done when it's the top priority for someone. You, me, any
other contributor, doesn't matter. Putting your hands on your hips and
demanding that someone else do work for you is just petulant.

[Aleve Sicofante (sicofante)]

There you go guys: we're just a bunch of petulants. That's PR at it's best Mr. Shuttlerworth. Good job, as usual.

[Alistair Buxton (a-j-buxton)]

Mark, YOU broke this, so it is YOUR responsibility to fix it. Not mine. Not the guy commenting above me. Not any other contributor to Ubuntu. You alone drove through these changes in the face of massive resistance, and by doing that you have taken on all responsibility for ensuring they work properly. If you don't want to make it your top priority that's fine. As long as we all know where we stand: that fulfilling your responsibilities toward the community is not a top priority for you.

"We can all make mistakes; when we do, we take responsibility for them." [except when it isn't a top priority.]

[Brad Jensen (bradwjensen)]

I first came to this bug report because I'm so frustrated with the way the Global Menu has been implemented.

First of all, WHY are we auto-hiding menu options? The fact that a menu is hidden without hovering over it with the cursor is insane! All that does is cause confusion, and hides options that others might be looking for or wishing they had that they didn't know existed (because they're hidden)! Menu options should be visible at all times, where they can be discovered and easily/quickly clicked on.

Right now, with everything being auto-hidden, I have to remember the menu is up at the top left of the screen (when my window is small rather than maxed), and then I have to hover the panel to see my options (very annoying/time consuming), and then I have to find the right option (if it was always visible I would have already found it), and then continue selecting what I originally wanted to accomplish.

Comment #24 is 100% correct.

By having the menu on the window itself, when not maximized, people have to move their eyes less, and move their arms and cursor less. It saves time and it and makes sense because the menus are connected to the app you are currently working on. By placing them in the global menu for a non-maxed window, you are confusing people as to what those menu options actually belong to, especially when you have to change focus from app to menu or to other app. Even the desktop has it's own menu..

[x] Global Menu only for maximized windows makes the most sense.

Most people on small screens run their apps maximized to get the most space possible, so naturally, placing the menu in the global menu when windows are maximized keeps the menu in the same areas as when the window is non-maxed (attached to the top left of the app), and it saves space by removing an extra bar. When people have very large screens they tend to use smaller windows and would appreciate having menus attached to each app, so it's easier to know which menu belongs to what app, as well as keeping the user from having to move their eyes, arms, and cursor very far to get to what menu they want (it's faster and easier.) They won't have to worry about what app has focus to know which menu they're working with..

So the solution is simple! When windows are maxed use the global menu, and NEVER auto-hide them; at it saves space, but is also technically the same thing as having the menu on the app window itself because it appears in the correct area of the window itself (and it's not confusing because it will never be auto-hidden.) When windows are not maxed, keep the menu attached to the window itself, so people have less to think about, and less hand/eye movement (It's also faster and easier.)

On a side note.. Showing the title before the menu is kind of annoying as well.. If anything, the title should be placed after the menu so the menu and close/max/min buttons are always in the same place.

[Aleve Sicofante (sicofante)]

2013/1/23 Brad Jensen <email address hidden>

> WHY are we auto-hiding menu options?

Because the owner of the playground believes it's more aesthetically
pleasing and that the menus are disturbing, ugly and awkward. He also
believes this pack of peculiar opinions form a "rationale". Basic logic is
not his forte. He's much better at insulting people (remember: the 600+
people subscribing this bug and opposing his "rationale" are a bunch of
"petulants"). There's nothing that can be done. It's his money, it's his
product, if you don't like it, look elsewhere or hope for the day he
doesn't make or approve design decisions any more.

You can also trust the few brave souls, capable of coding, capable of
pushing the many rational objections there are to this ridiculous decision
and expect them to fix it. I do, and I hope we'll see this fixed someday,
making Ubuntu a much better OS, UI-wise, inspite of the childish attitude
of the man in charge.

[Chad Germann (cgermann)]

[ x ] Global Menu on
[ ] Global Menu off
[ ] Titlebar only for maximized windows

Is bit a proper fix its just trading an annoying behavior of the global menu for an annoyingly inconsistent one. interface fetures should not jump around like a Jack Rustle terrier.

the fix should be

[X] Global menu on
[X] Global Menu off

And just remove the vanishing functionality completely. its not like that panel area is being used for anything else.

[Aleve Sicofante (sicofante)]

2013/1/24 Chad Germann <email address hidden>

> And just remove the vanishing functionality completely. its not like
> that panel area is being used for anything else.
>
> It's used for the window's buttons and title when in maximized mode, and
the application name when non-maximized. The solution is to show the title
whenever the mouse reaches either the top left corner (application title
area when not maximized, buttons area when maximized) or the area between
the menu and the indicators. In other words: show the title of the window
whenever the mouse is on the top bar but outside the menu area.

[Chad Germann (cgermann)]

> It's used for the window's buttons and title when in maximized mode, and
>the application name when non-maximized. The solution is to show the title
>whenever the mouse reaches either the top left corner (application title
>area when not maximized, buttons area when maximized) or the area between
>the menu and the indicators. In other words: show the title of the window
>whenever the mouse is on the top bar but outside the menu area

And we don't see the problem with this whole thing by how many words it took to type that? The whole behavior of the panel is convoluted and, it does not need to be!

 Question one Why do I need to see the application name on a full screened application if I set it to full screen I am pretty sure I will remember what that application was and, why is this more important than necessary application controls? There are a Whole Family of applications and most of them are the Type //people use to get work Done// that heavily use the Applications menu.

Re think the Panel behavior, Move things around, Let users set a black list of applications to not use the global menu just do something to keep NECESSARY CONTROLS from vanishing or Shifting around on the screen.

[Aleve Sicofante (sicofante)]

2013/1/28 Chad Germann <email address hidden>

> >in other words: show the title of the window
> >whenever the mouse is on the top bar but outside the menu area
>
> And we don't see the problem with this whole thing by how many words it
> took to type that?

Actually, my "other words" are pretty few. You bet I would have employed a
lot less words if I described this in Spanish, which is the language I
master.

  Question one Why do I need to see the application name on a full
> screened application if I set it to full screen I am pretty sure I will
> remember what that application was

I agree, but some people might argue the name of the document is useful to
know, even on a maximized window. Obviously, on a non-maximized window, the
vanishing menu is pure nonsense, let alone the softly truncated application
name when the menu appears. This behaviour has never been rationally
explained (probably because it can't be) and responds only to some personal
aesthetic preferences (guess who's...).

> There are a Whole Family of applications
> and most of them are the Type //people use to get work Done// that
> heavily use the Applications menu.
>

That's the whole reason this bug exists and is shared by so many people
here... I think the proposed solutions would alleviate the main problem
which you have defined very well. It's still hard to understand why
Canonical/Shuttleworth believes this is a minor or non-issue and keeps
postponing the implementation of a solution (or leaving it up to the
"petulants") that seems to be clearly resolved from a design point of view.

[Mikael Strom (mikael-sesamiq)]

I think this issue is a symptom of a much deeper problem; Canonical need a good designer that understand users behavior and can create a consistent UI. Many ideas are good in Unity, but the overall execution and UI-design is flawed and lacks consistency. Mark is clearly not the man to make this kind of decisions - he need someone that understands UI and design (read "Jonathan Ive, mk II"). It's no coincidence that Apple have been successful on consumer products - understanding user behavior, careful UI design and aesthetic perfectionism. Don't get me wrong, i love the Ubuntu, i just wish it will become what it could be. Mark; please realize your limitation surround yourself with right people for the job.

[Aleve Sicofante (sicofante)]

LIM has been announced for Saucy. I understand it's not a proper announcement, but just an idea in the ongoing UDS.

Whoever is attending the UDS, please remind the team of this hugely followed bug. If they're planning an overhaul of the menu system, they should pay attention to everything that has been said here.

[Leonardo Donelli (learts92)]

Selection bias. This is a bug report in which the global menu functionality on unmaximized windows is reported as a bug. Of course the vast majority of people on this page are against this feature. So I'll speak in favor of it.
Personally i love global menu (both on maximized and unmaximized windows) and it's *the* feature that keeps Ubuntu my OS of choice. Since when I got used to it "no global menu" -> "not an options as personal OS " (and my screen is 1600x900, for those saying that if the screen is > 1280x1024, than global menu is bad)
For those talking about auto-hiding and 'easy discovery of menu options': there's HUD for that now. It's amazing. The concept behind it has been proved successful in the past, on desktops: dash/launchers vs desktop icons, web search engines vs web directories.
Example: I wonder if GIMP has a function for lens flare. With HUD i press alt and type 'flare'. With the menu, i explore lists and sublists of menus categories until I find it (assuming I don't miss it)- The only case when the normal menus are better is when I want to just 'explore' the options, without looking for anything in particular ("Let's see if there is something cool"), How many times does that happens? 1 per application per lifetime? Well, for that time you can do the enormous effort of moving the mouse a little higher.
A lot of people here lamenting Unity sounds a lot like those windows users that try some distro and say "Where is the start button? What, there isn't one?! This OS is stupid!".

That being said, unless it's difficult to implement (I doubt it) I don't see why not give the users the option to disable it.

[Aleve Sicofante (sicofante)]

@Leonardo Donelli: Have you actually read this bug report at all? People
here is not against the global menu per se. Gosh, even the title says it
very clear!!! All we want is IMPROVEMENT, which in this case means some
pretty well argued options (compared to the total lack of rationale for the
current status...).

The HUD doesn't solve the problems illustrated here. It's just a different
way of accessing the menus (keyboard vs mouse), not a reason to hide them.

[quequotion (quequotion)]

>>Leonardo Donelli
HUD is not amazing. It's extremely inconvenient and nigh-useless. I can't imagine anyone actually making use of that poorly designed garbage. I really have nothing nice to say about this "feauture" except that I appreciate having a place to disable it in ccsm.

As for the global menu, I'm pretty happy with it.

I'd be more happy if it could pick up menus from SUID programs, so I could have a consistent interface.

I would like to see it more clearly distinguish the begining of the menu from the close/restore/minimize buttons, and I've always had a dream that someday developers will learn how to export menus from applications running through WINE.

I also dream of development toward a more portable / intercompatible global menu to use with other desktops, or more flexibilty with menu designs, which requires cooperation from the various desktop development teams.

Some of that dream:
Since it exports menus over D-BUS, it can send them anywhere. They don't have to be a menu across the top. The elementary developers have their own ideas for menu placement: a single menu button in one corner of the program. Some users might like that a lot, others want menus in programs like they used to be, and others like me enjoy a global menu. Why not develop a configurable menu-exporter? Something that picked up the menu over DBUS and then sent it to a user-configured location.

[Aleve Sicofante (sicofante)]

This bug isn't fixed in 13.04 yet.

Maybe the developers John Lea and Marco Trevisan (Treviño) could chime in and let everybody know if we can expect it to be fixed in 13.10?

Thanks.

[Aleve Sicofante (sicofante)]

Sorry for my ignorance. What exact changes have happened to Compiz
regarding this bug that you're informing us about here?

2013/7/22 Sam Spilsbury <email address hidden>

> ** Changed in: compiz
> Milestone: 0.9.10.0 => 0.9.10.2
>

[papukaija (papukaija)]

It means that the work/fix has been postponed to a later release of Compiz.

[Aleve Sicofante (sicofante)]

I'm confused.

This bug can only be solved in future versions of Unity. Since current is
Unity 7 and the design hasn't been changed, our first hopes go to Unity 8,
where Compiz won't be used at all. So unless Unity 7 introduces the desired
behavior in 13.10, which seems unlikely (since nobody has even mentioned it
so far) what exactly does all this "Compiz fix at a later release" means at
all???

2013/7/22 papukaija <email address hidden>

> It means that the work/fix has been postponed to a later release of
> Compiz.
>

[Alexandre (alexandre-j-navarro)]

Some news on this feature? It is my last major feature I want to see in Unity. Any plan to have it in 14.04 with Unity 8, it should be great ?

[Ingo Gerth (igerth)]

Unity 8 will not land before 14.10, at the earliest. Since they are not going to add new features to Unity in 14.04, do not expect to see this for years around.

[Ryan Koesters (rmkoesters)]

I don't know the current status of this bug, but I made a patch to fix part of the issue.

The patch adds a GSettings option (com.canonical.Unity.Panel.menubar-always-visible) that allows making the global menubar always visible.

This patch was done with the unity in 13.10 repos right now, but it will probably work with trunk as well.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "This patch adds a GSettings option to enable having the global menubar always visible (com.canonical.Unity.Panel.menubar-always-visible)." seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Mateusz Stachowski (stachowski-mateusz)]

The patch provided by Ryan Koesters works when applied to Unity in 13.10.

I've build Unity and then I had a new GSettings option. When I checked that menubar-always-visible the global menu became visible all the time for all programs.

This should be available in 14.04 LTS for the people that don't like the default hiding of global menu. Of course it would be even better if this could be toggled from Appearance settings instead of dconf-editor.

[Ryan Koesters (rmkoesters)]

@Mateusz Stachowski: I am currently working on a patch to do that for unity-control-center.

[Aleve Sicofante (sicofante)]

Will this patch "resist" updates?

2013/12/4 Ryan Koesters <email address hidden>

> @Mateusz Stachowski: I am currently working on a patch to do that for
> unity-control-center.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/682788
>
> Title:
> Improve Unity Global Menu
>
> Status in Ayatana Design:
> Fix Committed
> Status in Compiz:
> Triaged
> Status in Unity:
> Confirmed
> Status in “compiz” package in Ubuntu:
> Triaged
> Status in “metacity” package in Ubuntu:
> Triaged
> Status in “unity” package in Ubuntu:
> Triaged
> Status in Baltix GNU/Linux:
> Confirmed
>
> Bug description:
> ===+++ _____________________ ! ALL USERS ! _____________________ +++===
> ===+++ READ THIS BEFORE MAKING A COMMENT OR MODIFICATION +++===
>
> IMPORTANT 1: Please don't post any "me too message"; use the "Does
> this bug affect you?" feature you can find a bit above this bug
> description on Launchpad.
>
> IMPORTANT 2: Do not post anything if you haven't read all comments to
> verify that your point hasn't been made. If you feel tempted to stop
> reading because there are too many messages, that is a strong
> indicator that you shouldn't add even more comments. Developers have a
> tough time to find anything if you post redundant stuff. So please
> abstain from doing that.
>
> =========
> Global menu in general (not only in Unity) is very unergonomic on large
> screens (see the attached screenshot) because if you have a small window
> somewhere near the low right corner you have to move the cursor all the way
> up to to panel to reach the menu. I understand why the global menu was used
> for the netbook edition (it saves space and most windows are maximized),
> but since Unity is intended to be for the desktop edition there should be
> an option to switch to the traditional position of the app menu. It would
> be welcomed by many desktop users. Please try to find a solution for it
> that works.
>
> A commonly suggested solution is:
> [ ] Global Menu on
> [ ] Global Menu off
> [ ] Global Menu only for maximized windows
> The default is usually suggested as either the first (on) or last (on
> only for maximized windows).
>
> -------------------------------------
> Desired change:
>
> Implement the 'Enhanced Menu' project for 12.10. This project will
> address the issue described in this bug and also issues described in
> the duplicates of this bus. Note this is the 'official' bug that
> tracks the implementation of this project.
>
> The following options will be added to 'System Settings/Appearance':
>
> -------
> Menus
> Location: Global/Local
> Visibility: Hidden/Always displayed
> -------
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ayatana-design/+bug/682788/+subscriptions
>

[Ryan Koesters (rmkoesters)]

@Aleve Sicofante: Can you explain what you mean by resist updates?

I attached the patch for the newly forked unity-control-center that adds the option to enable or disable "com.canonical.Unity.Panel.menubar-always-visible".

[Aleve Sicofante (sicofante)]

2013/12/4 Ryan Koesters <email address hidden>

> @Aleve Sicofante: Can you explain what you mean by resist updates?
>
>
I mean, will we have to apply the patch after each update? Sometimes
updates overwrite patched versions of Unity. I'm asking if this patch
suffers from the same or is it independent from ordinary system updates?

[TomasHnyk (sup)]

Thanks Ryan, if you could also implement a toggle to use global menu with maximized applications only, that would be great!

BTW: does the patch in its current form ever display window's title for maximalized windows?

[Ryan Koesters (rmkoesters)]

@Aleve Sicofante: As far as I can tell, you will have to apply the patch every time.

@TomasHnyk: The patch doesn't show the title for maximized windows.

[Mateusz Stachowski (stachowski-mateusz)]

@Ryan Koesters: I've build today Unity and unity-control-center with your patches on Ubuntu 14.04 both worked without problems. I had to manually specify the files to patch unity-control-center because I probably used wrong -p option:

patch -p1 <

To install the packages I had to remove gnome-control-center-unity because it was in conflict with this new unity-control-center. This is screenshot of u-c-c with always show the global menu bar option.

http://ubuntuone.com/1JH80LwIm4Su2OM6gkYK5i

I had troubles with building the current Unity for 14.04 but not because of your patches so I used the daily build from Unity daily stack preparation PPA.

https://launchpad.net/~ubuntu-unity/+archive/daily-build

Your patch applied successfully but there were some offsets. Packages for Unity build without problems. When I installed new unity and libunity-core packages I had the menubar-always-visible option in dconf Editor.

http://ubuntuone.com/52zSHb6qp1Sd4zMj4XCefh

[David Wolfe (davidw+launchpad)]

Some here seem to have a conceptual misunderstanding about human interface design. Technology and design improvements should increasingly conform the computer to the human, not the other way around. Confoundingly, not all humans work the same way. Regardless of which side of the debate you take, the hubris in the lack of configuration (formerly a highlight of Open Source) is inescapable. And, frankly, unreasonable.

So here we are, two years of argument later and no significant progress. All to save what? 24 pixels of vertical space? Ludicrous.

[Aleve Sicofante (sicofante)]

2013/12/8 David Wolfe <email address hidden>

> All to save what? 24 pixels of vertical space? Ludicrous.

Actually the global menu per se is not the issue here. Almost every
commenter likes it; just not the way it behaves _exclusively_ (not "by
default", since there are barely any options). So I would rephrase to say
"All to save what? A few hours of a developer introducing the already
designed options and just a maybe bigger but better code to maintain?"
THAT's the "benevolent dictator"'s responsibility and only his (just read
his despising words along the whole thread). His disdain for proper
reasoning and logic is simply appalling and frankly depressing.

Here's hope that some of the brilliant minds at Canonical (definitely not
his), will take on the responsibility of making Unity 8 a better Unity by
including AT LEAST the chance of add-ons that allow third parties to tweak
it. Creating non-extensible software in 2014 sounds unbelievably
prehistoric, so -again- I expect that we have AT THE VERY LEAST, an
extensible-by-design Unity. At that point, we can stop worrying about
Shuttleworth's reasoning skills and simply build persistent add-ons instead
of patches that will be overwritten every other week.

[Doug McMahon (mc3man)]

14.04 users can now, if desired, disable global menus on a per app basis in dconf. Should work for most common apps excluding nautilus, firefox/thunderbird & any qt4 apps like vlc, smplayer, ect.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Phillip Susi (psusi)]

Marco, the branch you linked appears to be two years old and was rejected, so how does that make this Fix Committed?

[TomasHnyk (sup)]

Is not it this: http://www.omgubuntu.co.uk/2014/02/locally-integrated-menus-ubuntu-14-04?utm_source=rss&utm_medium=rss&utm_campaign=locally-integrated-menus-ubuntu-14-04&utm_reader=feedly

[Aleve Sicofante (sicofante)]

Nice, but the menus keep vanishing. This doesn't really solve one of the
most controversial issues. There must be a way to have the menus
permanently visible. Many (myself included) would rather have the window
title vanishing, making it visible when hovering over windows buttons or
the empty area to the right of the menu, for instance.

Otherwise, very nice indeed.

2014-02-20 23:33 GMT+01:00 TomasHnyk <email address hidden>:

> Is not it this: http://www.omgubuntu.co.uk/2014/02/locally-integrated-
> menus-ubuntu-14-04?utm_source=rss&utm_medium=rss&utm_campaign=locally-
> integrated-menus-ubuntu-14-04&utm_reader=feedly
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/682788
>
> Title:
> Improve Unity Global Menu
>
> Status in Ayatana Design:
> Fix Committed
> Status in Compiz:
> Invalid
> Status in Unity:
> Fix Committed
> Status in “unity” package in Ubuntu:
> Triaged
> Status in “unity-control-center” package in Ubuntu:
> Triaged
> Status in Baltix GNU/Linux:
> Confirmed
>
> Bug description:
> ===+++ _____________________ ! ALL USERS ! _____________________ +++===
> ===+++ READ THIS BEFORE MAKING A COMMENT OR MODIFICATION +++===
>
> IMPORTANT 1: Please don't post any "me too message"; use the "Does
> this bug affect you?" feature you can find a bit above this bug
> description on Launchpad.
>
> IMPORTANT 2: Do not post anything if you haven't read all comments to
> verify that your point hasn't been made. If you feel tempted to stop
> reading because there are too many messages, that is a strong
> indicator that you shouldn't add even more comments. Developers have a
> tough time to find anything if you post redundant stuff. So please
> abstain from doing that.
>
> =========
> Global menu in general (not only in Unity) is very unergonomic on large
> screens (see the attached screenshot) because if you have a small window
> somewhere near the low right corner you have to move the cursor all the way
> up to to panel to reach the menu. I understand why the global menu was used
> for the netbook edition (it saves space and most windows are maximized),
> but since Unity is intended to be for the desktop edition there should be
> an option to switch to the traditional position of the app menu. It would
> be welcomed by many desktop users. Please try to find a solution for it
> that works.
>
> A commonly suggested solution is:
> [ ] Global Menu on
> [ ] Global Menu off
> [ ] Global Menu only for maximized windows
> The default is usually suggested as either the first (on) or last (on
> only for maximized windows).
>
> -------------------------------------
> Desired change:
>
> Implement the 'Enhanced Menu' project for 12.10. This project will
> address the issue described in this bug and also issues described in
> the duplicates of this bus. Note this is the 'official' bug that
> tracks the implementation of this project.
>
> The following options will be added to 'System Settings/Appearance':
>
> -------
> Menus
> Location: Global/Local
> Visibility: Hidden/Always displayed
> -------
>
> ...

[Aleve Sicofante (sicofante)]

May I suggest we take a look at the description of the bug? At the end it says:

The following options will be added to 'System Settings/Appearance':

-------
Menus
Location: Global/Local
Visibility: Hidden/Always displayed
-------

Location has been masterfully solved by Trevilño. The second one is just a switch/checkbox away. C'mon we're almost there!!!

[Morais (jmsmorais85)]

Hi!

Will the "Visibility: Hidden/Always displayed" option be added to the "System Settings/Appearance", in Ubuntu 14.04? Or is it too late? Would something like the screenshot in the attachment be possible for unmaximized windows? Thanks.

[Aleve Sicofante (sicofante)]

I proposed exactly that to Marcon Trevisan and he asked me to look for John Lea on IRC. I confess I haven't had the time (I've never used IRC before and haven't even learned how to).

Here's my proposal: http://blog.3v1n0.net/informatica/linux/ubuntu-introducing-locally-integrated-menus-to-unity-7/?utm_source=twitterfeed&utm_medium=twitter#comment-1270843203

(there's a pretty interesting talk in the comments at that Marco's post)

While it probably is too late to put the title on the screen top bar and the menu permanently visible on the window title bar, Marco said he would put some gconf/dconf setting to make the menu permanently visible.

[Stephen M. Webb (bregma)]

Fix Released in Unity Unity 7.2.0.

[Aleve Sicofante (sicofante)]

2014-04-03 3:55 GMT+02:00 Stephen M. Webb <email address hidden>:

> Fix Released in Unity Unity 7.2.0.
>
> ** Changed in: unity
> Status: Fix Committed => Fix Released
>
>
This is simply not true. Only half of the problem has been solved. The
visibility issue has been ignored by the design team so far. I don't know
if Marco has included the gconf/dconf key to partially palliate the problem
but that IS NOT a solution to the visibility part of this bug, only a
quick'n'dirty patch.

Please don't mark as fixed a bug that's only half fixed.

[Mantas Kriaučiūnas (mantas)]

I can't find any dconf (gsettings) setting to make the menu permanently visible in Ubuntu 14.04 (Unity 7.2.0+14.04.20140416) :(

Marco Trevisan, it seems you forgot to add dconf setting to make the menu permanently visible, right?

Aleve Sicofante (sicofante) wrote on 2014-04-02:
> Here's my proposal: http://blog.3v1n0.net/informatica/linux/ubuntu-introducing-locally-integrated-menus-to-unity-7/?utm_source=twitterfeed&utm_medium=twitter#comment-1270843203
> (there's a pretty interesting talk in the comments at that Marco's post)
> While it probably is too late to put the title on the screen top bar and the menu permanently visible on the
> window title bar, Marco said he would put some gconf/dconf setting to make the menu permanently visible.

[Alexandre (alexandre-j-navarro)]

I also can't find any dconf (gsettings) setting to make the menu permanently visible in Ubuntu 14.04. How to do that?

[Aleve Sicofante (sicofante)]

2014-07-10 21:59 GMT+02:00 Stephen M. Webb <email address hidden>:

> ** Changed in: compiz
> Milestone: 0.9.11.0 => None
>

Does this mean this will never be fixed? We're still waiting for the option
to keep the menus permanently visible...

I have a few Ubuntu installations (a lawyers office in particular) where
users are complaining about not finding the menus. Will I have to
completely uninstall the global menu?

[Stephen M. Webb (bregma)]

> Does this mean this will never be fixed?

No, the milestone target for the upstream Compiz project was removed because this task does not affect the upstream Compiz project, it's purely a Unity thing.

[Aleve Sicofante (sicofante)]

May I ask what fix was released, Marco, and what's exactly the nature of the fix? Has it been fixed for the current Ubuntu version (14.04.1) or is it fixed for an upcoming one? If it's the latter, which one: 14.10 or/and 14.04.2?

[Marco Trevisan (Treviño) (3v1n0)]

@Aleve:

This bug was actually fixed by the Locally Integrated Menus release, but as for the option to make the menus always visible is something that we're going to fix ASAP.

By the way, since I think that it's a different bug, then I prefer to close this and moving to another clean bug for the visibility thing (and feel free to open it, if there isn't another).

[TomasHnyk (sup)]

Marco: that would be this bug: https://bugs.launchpad.net/ayatana-design/+bug/955193 - right? It is a duplicate of this one but has some design to it.

[Aleve Sicofante (sicofante)]

Four years have passed and we still have no permanent menus and most of the issues posed by this bug remain acknowledged but unsolved. I can't quite get what the process is, but it just isn't working.

Are these issues being looked at in Unity 8 at least?