Global menu doesn't work well with more than one screen

Hi Chris

We definitely need to solve this for the non-FFM case. I'm afraid you
are on your own with FFM.

Do you think it would feel most natural to have different menus on
different screens, related to the app on each screen which is focused?
AIUI there is only one focused app, even in a multi-monitor setup, so
the menu really applies to that even if it's not on the screen where
your mouse is.

Mark

Hi,

I just upgraded to Natty and spent an evening playing around with the new unity launcher + global menu setup on a few different screen sizes. Short answer is 15" & 17" things are great, 22" single it starts to feel uncomfortable, 22" Dual things are really uncomfortable. My suggestion is that the global menu only kicks into play when the window is maximized, or potentially only when it is within a certain distance of the top panel (I have *no* idea of how feasible that is, so that might be asking for a gold-plated plane that flies for all I know...)

Resolutions tested at were:
- Dual 22" monitor: 1680x1050 + 1680x1050
- Single 22" monitor: 1680x1050
- Single 15" Laptop: 1280x800
- Single 17" Laptop: 1440*1024

Basically, for the 15" & 17", the global menu works generally well. As you stated Mark, most of the time there is only one application that is the main focus, and even on the upper limit (e.g., I'm transcribing notes from a webpage to a word document), there are generally few enough windows in focus due to the screen size that I have only one or two "primary" windows (i.e., non-popup windows that I will want to interact with the menus occasionally). Even if there are multiple windows, the top border is not far enough from the other windows to feel arduous (lower if horizontal split, right-most if vertical).

For the 22" single, the story started to change a bit. At 22", the screen starts to feel big enough for more than two activities ongoing in the same workspace. One rather typical example is I will have a file browser, a web-browser and a html editor all open. At this point, windows that touch the top bar are intuitive and simple enough to use, but windows down the bottom (e.g., horizontal split) do start to feel "annoyingly" far from the menu bar up the top. It is survivable, but one does start to notice the extra distance travelled quite soon (i.e., 30mins+).

For the dual 22" screen, I am finding I usually have ~4 primary applications going at the same time. For example, a web browser, a html editor, a chat program and a file browser. At this point, the windows are arrayed all over the dual screen, usually with the web browser and html editor being maximized, and the file browser and chat window being small and always on top. The global menu works well for the maximized window on first screen, and I believe your suggestion mark would address the maximized window on the second screen. However, the smaller "portal" type windows feel completely broken at this point due to the distance required to travel to get to the menus. Things feel even worse as I need to cross the big maximized window to get there, and in my case, I usually have follow-mouse-focus turned on, which means the bigger window grabs the global menu on the way over.

As suggested at the beginning, on a 22" dual, I'd definitely prefer small windows near the bottom of the screen did not use the global menu. Small windows at the top are much of a muchness, as the distance to the menu is small.

Also... can I have a pony? :)

Perhaps a possibility would be to transition from local menu to global menu when the distance between the two would increase beyond some value ($X hundred pixels). On smaller or fullscreen netbook displays the top of the windows would always end up near the close to the top of the screen (the distance would be short).

But, on a larger screen and a window nearer the bottom, the menus would be attached to it. Such an approach might also serve to solve the multiple desktop paradigm; if the window was far enough away to be on a separate physical monitor it could then be transitioned to local menu. In this case when crossing the window boundary.

The loss of vertical space would be zero for a full-screen window on a second monitor as the global menu/top panel real estate would be absorbed by the local menu attached to the window. A smooth transition would probably need implementing so that it is clear to the user what is happening (similar to snap alignment when the point reaches a certain threshold) and that it is reversible by recrossing the threshold.

Philip, thank you for taking the trouble to do such comprehensive and
rigorous testing, and to write it up so clearly. It's a really useful
bit of analysis and feedback, which we will definitely factor into our
design and decision making.

The piece we're not going to try and solve is the focus-follows-mouse
problem. There's a proposed design for that, and a patch implementing it
would be accepted for testing, though it's a hard problem and we're not
even sure that design would really work. As you noted, FFM really
compounds the issue of having multiple windows on the desktop and having
to traverse them to get to a menu.

I think the observations you make about traversal time are valid. Paul
Sladen's suggestion of having a threshold for the use of the global menu
is interesting too, and worth testing, though we generally try not to
have magic thresholds where behaviour changes. I'll ask Paul to find out
from Cody if there's a quick way to hack this in for testing purposes.

Mark

Nb to self subscribing to "configure-event" signal helps, but this is only getting sent once /after/ the window has reached its new position, and not continuously during the move.

I've attached a branch which is pretty much a quick hack. It's hard-coded to check if the window is above/below 200px on the screen, which is wrong but it gives you something to work from.

Paul, if you can set that to 600px and stick it in a PPA, I'll give it a
whirl. Cody, does it update dynamically? I.e. resize the window for the
menu if you move it across the threshold?

Yes, it updates dynamically.. kind of.

I have my WM set to resize opaquely, not using an outline or something, so when I resize my window then the application actually receives configure events and repaints the window. In this situation, if I raise or lower the top edge of the window then the local menubar will appear or disappear.

If you're doing something that the WM has control of, this isn't quite the case. If you grab the titlebar of a window and start dragging it around, the client application never receives a configure event until you release the mouse. So if you drag your window above or below the threshold you won't see immediate visual feedback until you release your mouse.

Mark: grab:

  deb http://ppa.launchpad.net/sladen/ayatana/ubuntu natty main
  appmenu-gtk=0.1.9-0ubuntu5~ppasladen1

Yes, if you resize (as well as move) a window up and down past the 600 pixel threshold then it the local menu appears/disappears. Note that won't already work for gnome-terminal /itself/ reliably and you may get white strangeness (I pulled my hair out for several hours before thinking to try something else, I suspect gnome-terminal is using that the configure-event signal for itself and there might be something up with the chaining). Again, beyond the scope of a quick test.

Best way to test, if you load gnome-terminal, and then run gedit from inside that and move/resize the top of the gedit window past the threshold.

It is not smooth (the event is only fired when the window drag is released), so if it's a solution we'll need to figure out what other events are available, or synthesis the necessary from the Window Manager (Compiz in this case so shouldn't be too much of a problem).

I know I am jumping into this kind of late but I had a minor brainstorm.

It seems to me that the case of the huge monitor is of course important, it is also less common. Multiple monitors however is indeed quite common. My solution is as follows:

1) The top bar only extends across the primary monitor
2) When a window is on the primary monitor, its menus are displayed where they are expected
3) When a window is on the secondary monitor, a second menubar slides in from the top of that monitor as an overlay (maybe nice rounded edges, whatever). The menus are held in there. Window decorations could be designed to make sure this looks clean with maximized windows. The transient bar should look a little different from the primary bar to re-enforce that it is not a panel, just a container for menus.

In this solution there is no permanent bar across the top of the secondary monitor (a transient one will show if needed). Mouse travel times are reduced dramatically and application interactions are properly contained into a single monitor. Oh, and it's pretty easy to do :)

I think the idea of a second panel is better than a transient menubar.

A second panel would consume additional screen real estate that people are plugging in a second monitor just to gain. It feels wasteful.

Balance, Jason.

Sorry, my fault -- I thought I had included this in the specification a year ago, but I'd left it out. I've fixed it now.
<https://wiki.ubuntu.com/MenuBar?action=diff&rev2=27&rev1=26>

Thanks MPT. I am offline so can't read the full diff to the spec, but I
think we will want to test the idea that there is some coupling between
the menu displayed on a screen, and the last app focused on that screen.
In other words, the menu might be different on different screens.

Mark

I was also wondering about this. I use dual screens and feel that currently it is not efficient for me to have an application in the second monitor which requires me to use menu's in the first. I really like the idea of the second panel, however, the sliding effect, if implemented, should be implemented very very smoothly...else the panel should just be permanent and the sliding avoided.

The secondary panel appearing when a window appears on that screen will be frequent for those of us with more than one screen attached and it just seems more professional to just leave the panel at the top of the screen since it will apparently always be there when that screen is in use. There is also no use in wasting CPU cycles to slide a panel in that will always be there when that screen is being used anyway. For consistency of appearance it also seams like a good idea to just leave the secondary panel visible at all times. Why would you show that extra bit of space when its actually going to be occupied when a window enters that screen?

I too use a dual 22" setup with nvidia twinview and after testing natty for a while agree with what Philip said:
- When a window is maximized on the second (right) monitor the global menu should be on the the panel on that monitor.
- non-maximized windows should not use the global menu as it increases the travel distance quiet a bit and feels unintuitive with many windows open.

I personally think a distance triggered global menu would fell gimmicky, but I cant say for sure since I haven't tested it.

I really love how the panel spawns both monitors by the way, makes both monitors seem more part of a single big desktop. Locations of menus (dash or shutdown for example) also stay consistent in respect to the edge of the active screen for people who switch between single and dual monitor configurations, as I do (since many full screen games don't play nice dual monitors).

Olivier, please *do not* add newly installed apps to the launcher
automatically. We need to:

 (a) expose recently installed apps in the Apps Place
 (b) create a means to drag app launchers from Software Centre to the
Launcher when installing them

Mark

John, can you take me through the design? I'm expecting at least some
attempt to match menu to screen, with the potential for different menus
on different screens. If that's not what you've got, please refer to me.

Mark

The problem is that there are two (as I see it) external monitor work flows we need to consider.

These use cases are designed from a mix of intuition, personal use, physical observations of dual monitor users over the years, and from reading discussions related to dual monitor behavior in various applications.

1, A Desktop with two matching monitors: Users here use their monitors as one massive workspace. They do not really think of it as two monitors; that is just an implementation detail. They have everything laid out in front of them, and while they may generally separate their work by monitor, they still float things back and forth often and are usually aware of the entire space.

2. A laptop with an external monitor: Users of this configuration tend to use their secondary monitor as storage space. It's an edge of the desk for putting reference material, and other non-focused items. Gwibber idling to display new tweets, API documentation, reference material. The primary screen is the work area. It's in front of they keyboard* so while typing their attention is focused in that direction. It feels much less natural to have your head turned and be working in a different direction than your hands are pointing

So we need to design the multimonitor case with that in mind. The two means of working are rather different. The current behavior is very sub-optimal for the second case, of the laptop with an external. I feel that we can devise a very transparent dynamic system for this.

My proposal:
Have two configurations for how the panels get laid out, and menus behave. We can fairly reliably detect which case we should use. Xrandr gives a wealth of display information. If we see LVDS, we have a laptop. If we get a hotplug event, assume laptop case. Desktops don't get monitors plugged in and out of them very often. They tend to be static. We can probably even do some guessing based on screen geometries. I haven't seen too many dual monitor desktop users with differently sized screens. The super large desktop metaphor kind of breaks down here. This might be another hint we could use to decide.

Unfortunately I don't think that this is a problem where a one-size-fits-all solution will work, but luckily it's one where it should be relatively easy to make it just do what's implicitly expected.

*Some users also use a usb keyboard. I haven't seen very much of this so I can't really comment on how they use multiple monitors. I would guess that they would be a use case closer to 1 than 2, but I can't say.

I've been testing Unity and I've gotta add my concerns to this bug...

On my netbook, and 1440x900 laptop, the global menu feels like a good fit. However, on my 22" monitor and my dual work monitors it's really not a good fit at all. Wouldn't it make sense to just disable the global menu when the resolution hits a certain threshold or when dual monitors exist?

I mean, beyond 900 vertical pixels it seems we are generating a lot of usability issues just for the relatively minute vertical space saving (2.6%).

Also, it seems a bit backwards to me, making the decision to have a global menu, and THEN trying to work out how to wedge it into the common dual-monitor/high resolution use cases. Surely it's better to specify the problem that needs to be solved and THEN come up with a solution based on all the common use cases... perhaps the best solution to saving vertical space and improving usability wouldn't involve a global menu at all.

@Kazade:
I agree with most of what you said, but i don't think global menus should be disabled completely at higher resolutions. It always makes sense to use them on maximized windows.

It doesn't make sense to me, if Unity were to use a global menu, and (in
theory for this discussion) to disable it for larger screens, but then imply
it to maximized screens. It would seem inconsistent and unprofessionally
designed to me personally, if I were just coming to a new OS (and would seem
sloppy for use regardless).. Menus being placed at the far left edge of the
windows (no global menu), and then maximize the window implementing the
global menu forcing the menu significantly to the right and above where you
would expect it to be after using and getting accustomed to an un-maximized
window.

I would just like to point out the pro's and cons of the global menu (in my
opinion, with my every-day use)

Pros
-saves aprox 24px on normal windows
-after conditioning, will be quicker to get to a menu by habit (or skip that
conditioning, and stay with the conditioning most are use to already by
simply heading to the area right below the left edge of the window, so
technically this pro could be considered moot by some)

Cons
-even after conditioning, harder to get to/use on larger screens
-even after conditioning, harder to get to/use with multiple screens
-focus issues (finding window and bringing to focus, then moving away from
window for menu)
-many more steps if using two or more menus from two or more windows back to
back to back, especially if the windows are not placed near the panel, or
maximized...
-focus follows mouse issues
-if more than one window open (tiled on screen) confusing which window the
menu belongs to.
-when mouse hovers over the panel, it covers up a portion of the name of the
window it belongs to, in some cases makes one double check to make sure
which window is focused..

among a few minor other things

Honestly, to me using a global menu with all of these issues to save 24px on
larger screens seems to be backward thinking. It seems like a few people
think it's 'neat' and pawn it off as a forward step, when in my opinion it
really isn't. If it's being designed to fix "a problem" as I've heard in the
cirlces, but causing this many more (again my opinion) is it worth all the
hassle to keep the idea going, or is there a better way to fix the initial
problem? I would keep menus in the windows, and implement global menus where
it's needed, in a netbook..

I realize this sounds like I'm debating. I'm not looking for one, I'm simply
stating the usability bugs as I see them and proposing my simple idea for a
solution.

@walogreg:
Maximized windows merge with the top panel, so using global menu with them you have all your menus where you would expect them. (Except if it is on a second monitor, but that was discussed above and will hopefully be fixed)

Sorry, what I meant by that was...

Say you are using an un-maximized window with the global menu disabled
because of a large or multiple screen set-up. You get used to the menu being
directly below where the window control buttons are. If you maximize the
window, one would normally expect the menu to still be below the buttons,
not to the right of them simply because of the size of the window was
maximized.. Doesn't seem natural, logical, or consistent on a normal desktop
to me..

That is all..

On Thu, Feb 10, 2011 at 3:51 AM, Uli Tillich <email address hidden>wrote:

> @walogreg:
> Maximized windows merge with the top panel, so using global menu with them
> you have all your menus where you would expect them. (Except if it is on a
> second monitor, but that was discussed above and will hopefully be fixed)
>
> --
> You received this bug notification because you are a direct subscriber
> of a duplicate bug (688460).
> https://bugs.launchpad.net/bugs/683084
>
> Title:
> Global menu doesn't work well with more than one screen
>
> Status in Ayatana Design:
> Fix Released
> Status in Unity:
> Confirmed
> Status in “unity” package in Ubuntu:
> Incomplete
>
> Bug description:
> See https://wiki.ubuntu.com/MenuBar?action=diff&rev2=27&rev1=26
>
> Desired fix:
> The menu bar should appear at the top of every screen, except those
> screens where a window is currently in full-screen mode. (The menu bars on
> different displays should not be mirrors, however; opening the “Edit” menu
> on one should not simultaneously open it on the others.)
>
>
> Original bug description
> ------------------------
> I currently have a dual-screen setup for work (I dock my laptop with the
> lid up and use that with an external monitor, which I don't think is an
> uncommon setup), and the global menu is quite difficult to use. It's made
> even more difficult for me, because I use focus-follows-mouse too.
>
> The global menu currently only ever displays on 1 screen (the left-
> most screen for me). This has a couple of issues:
>
> 1) For windows I have open on the right-most screen, I have to
> navigate a long way (to the screen with the global menu on) just to
> open the menu.
>
> 2) It really doesn't seem obvious to which window or application the
> global menu is actually controlling
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ayatana-design/+bug/683084/+subscribe
>

Couldn't we move the menu next to the window buttons on unmaximized windows?
It seems to me that would solve the issue, as well as save the 24th px,
while avoiding the annoyances the global menu poses to unmaximized windows.

Of course, the global menu should still activate on small screens and
maximized windows.

Kazade, Uli Tillich, whalogreg, and Nicholas Christian Langkjær Ipsen: This bug report is about menu behavior on more than one screen. It is not about large screens, small screens, maximized windows, unmaximized windows, or anything else; please report any other bugs separately.

Summary from Neil of the current implementation in Unity:

"""
- Every monitor has a panel
- Only primary monitor has the Ubuntu button, the rest just have the
menubar + indicators.
- *The monitor with the active window* has a visible
menubar/appname/etc, other monitors do not show their menubar
- The menubar follows the active window, so if you move the window from
one monitor to another, the menubar goes to the panel on that monitor
- Even though you can't see the menubar, drag-down to unmaximise and
double-click to unmaximse still work on the panels for maximised windows
*that are on that panels monitor*
- Alt+$foo or F10 show the menu *on the monitor with the active window*
and cycling through the menus is contained to that monitor
- Dash/launcher stick with the ubuntu button on the primary monitor
"""

I've been working with 11.04 Unity and a dual monitor setup and I think that the current solution is OK except for one problem.

The Unity bar in the second monitor has , apart from the appindicators, also the clock and the menu to log out, etc. I think that the log out menu should be only in the primary monitor, but this is not important.

What's more important is that the system notifications come now always on the second monitor which I have on the right of the main one. This is not very convenient because no matter where I'm working I have to got to the far rightest place of my setup to see the notifications. Usually, at least for me, I use the second monitor to have processes that I want to have running but which I do not have to look for a long time. For instance if I'm wordprocessing or working with a spreadsheet I use the main monitor, and in the second monitor I have a statistical program running some analysis, or my email client open.

I think that the notifications should be always in the main monitor. I think also that it is not elegant to have all the bar icons duplicated across monitors, like the sound indicator, the network indicator, the close/open menu, the time and the menu for on-line accounts (show availabiility, etc). Maybe the only one that whould be duplicated would be the time/date indicator, since this one is useful to have handy, all the other should be only in the Unity bar of the main monitor.

Walter, notification bubbles are completely separate code. You're seeing bug 331369.

Yes, you are right. But it just started happening to me when I upgraded to Natty, so I thought it was Unity related.

I'd like to add my voice to asking for better support for FFM. It's /the/ usability reason for my choosing to work on Linux, and is getting to be /the/ reason for not using Unity (I have technical reasons for working on Linux, too, but they don't count much in a usability context).

I'd be happy enough if Unity simply did not put the menu into the global menu bar if FFM is enabled. That shouldn't be too hard to do, presumably, as standard GNOME can do it just fine.