"Global" appmenu breaks sloppy focus

I second this! I use sloppy focus all the time, it's one of the reasons I love Linux and I miss it when i have to use Windows

Popey, what about a hotkey which will shift focus to the mouse location,
without necessarily bringing the window to the front?

Mark

I will resist the urge to wonder why you are reporting a bug to tell us that you would like to file a bug.

In May, I specified how focus-follows-mouse might be catered for with the global menu bar. <https://wiki.ubuntu.com/MenuBar#focus-follows-mouse> I don't think it would be a good use of the Canonical DX team's time for them to implement it. I can't even guarantee that any future change in Unity's design wouldn't prevent that design from working. But I wouldn't mind if someone else implemented it.

I think that mpt just make the good summary. I'll mark it as triaged and as low as it's not the default experience of ubuntu. But if someone wants to contribute it and propose a patch with a full testsuite, I think that we will gladly merge it. That will be an awesome cocntribution :)

I like the proposal in https://wiki.ubuntu.com/MenuBar#focus-follows-mouse, but I realize that we won't implement it ourselves.

As a bandaid, would it be possible to dynamically disable the global menu if FFM is enabled?

Hi Martin

Yes, we can configure the global menu not to activate if FFM is enabled.
I'd be happy to accept a patch to that effect :-)

Mark

This has been discussed sufficiently now - there's a proposed spec, a
contributed patch would get a quick review and then user testing (we
don't know if the spec is actually good enough in the end till we test
it). For now, I'm marking this wontfix, but will leave this comment as
an invitation to someone who cares and has the skill needed, to provide
a candidate fix for evaluation.

 status wontfix

Mark

Might I suggest "wishlist" rather than "won't fix"? I've always taken the latter as "patches not welcome".

Here's a quick work-around. Many caveats included:

    ***

Change the indicator appmenu to to base the menu shown on window stacking
rather than solely on the input focus. This works slightly better under the
"sloppy focus" scheme.

There are, however, some caveats:

* I didn't test what happens with the usual click-to-focus

* There is no visual indication of which window has the menu.

* A patch to compiz is required to make the stacking be always up-to-date.

* Always-on-top and desktop windows are still handled the old way.
  The issue is that these windows never receive stacking changes,
  and therefore the only way to deal with them is via the input focus.

  Fixing this requires a complete separation of the menu focus from the input
  focus --- this can only be done within Compiz, and the information should
  from there be communicated to indicator-appmenu e.g. via a root window
  attribute.

I like the suggestion in comment #5- dynamically disable GM if FFM is on. However, it sure would be nice to find a way to get them to co-exist and not have to choose one over the other.

I'd like to offer another suggestion. Forgive me if it has already been discussed.

Under "Control Center" -> "Window Preferences", there are two options, "Select windows when the mouse moves over them" and a sub-option "Raise selected windows after an interval" with a tunable "Interval before raising". If "Select windows when mouse moves over them" had a similar option for "Interval before selecting", I think that might fix the problem. Delaying the focus change for just a few tenths of a second should let the pointer skip over intervening windows on its way up to the menu bar without losing focus on the original window.

Thanks! -jsj

I think I would find Jeff's suggestion in comment #11 to be frustrating. I often zip my mouse over to another window with just a nudge of one hand (one of the benefits of FFM after all) and then get back to typing virtually instantaneously. Any kind of delay that caused my input to go into the "wrong" window would be a problem for me.

I would like to propose a different solution:

Observation: People going for the global menu-bar generally take advantage of Fitt's Law and shoot the pointer straight upward, rather than meandering about.

Observation: People using focus-follows-mouse are generally in one of two states, either interacting with a single window or moving the mouse to focus a new window - they never interact with windows as they move the pointer past them.

Idea: Use 'is the mouse moving' as a heuristic to determine whether to focus the window under the pointer.

For example, the window manager could store the pointer coördinates when it receives a mouse-move event, then have a periodic timer that fires (say, once per frame) and compares the then-current pointer position with the last stored position. Because people rarely interact with windows while they're moving the pointer past them, and because the timer (once per frame, or ~19ms) is so much shorter than human perception (100-250ms), it shouldn't cause anyone grief - the only noticable change should be that reaching for the menu bar Just Works.

If the once-per-frame counter doesn't achieve the desired effect, the usual batch of UI adjustments would be available: running the timer faster or slower than once a frame, checking whether the mouse-pointer has moved by less than a certain amount rather than an exact "not equals" comparison, etc.

Unlike MPT's suggestion in the wiki, this would not require creation of a separate focus state; unlike the suggestion in comment #11, there's no fixed timeout that aggravates the slow (with false-positives) or the fast (with false-negatives). A single frame's delay should be much, much faster than the time required to move your hand from your pointing device to the keyboard, even if you're using a trackpoint. ;)

I've just started playing with Unity, and it strikes me that using the alt+key for grabbing the menu (and esc to cancel) seems to fit in with a nice workflow, particularly when I note that in actuality I rarely use the menus. The only problem is that I would like a unified key to do the grabbing. For the most part, alt+f will grab the file menu, but there is no guarantee that a file menu exists. Is there a key stroke I'm not aware of?

Yes, F10 will go to the first menu of the panel (first menu of the
application or first indicator if no menu).

Since this situation is marked a duplicate, I'll mention it here, too: With ffm on, and if any window is open (even gkrellm as a dock) you can't get a file on the desktop to take keyboard focus. Example: you can right click to rename a file on the desktop, but the keystrokes go to whatever window had focus last.

Oh, the alt trick in comment 14 is rather nice. Maybe I can deal with this after all. Still looking forward to a patch.

I'd like to add that the window focus can be made to *alternate* repeatedly between two windows. Switch on FFM and place your mouse cursor over the shadow that the topmost window makes.

Hint: I can use FFM almost like in the old days using the "ubuntu-classic" session and the ring-switcher for the alt-tab action. However, I am not convinced. I don't like the ring-switcher animation.

I view this issue as a serious regression, not a nice-to-have. I feel slapped in the face by my favourite distro.

OT rant: (Other grievances with the new ubuntu/unity: it is hardly
configurable. What happened to the good old right click? The menu to
select applications is clunky, showing only few results even though
there is a lot of unused space, and showing apps that aren't
installed instead. The new searchable menu requires a lot more clicks to reach
standard apps. Often, it needs both mouse and keyb interaction, which is
slow. Unity deprecates all those panel apps people use around the world,
which is hardly polite. The overlay scrollbar is a downright insult to
interface design, if one takes the liberty of not viewing it from a
touch device perspective. It can only be disabled system-wide, what's up
with that. And the worst is, sometimes button clicks and scrollwheel
actions seem to have no effect! I'm currently looking for all the right
issues to comment on about this. But I'm really really put off. Ubuntu
was a simple-to-install and get-to-work-right-away distro. Now I need
days of work to remove all the clunks put in my way.)

Hear, hear, neels. Focus-follows-mouse is very standard X11 behaviour (I even tweak Windows to use FFM when I can), and breaking it is a major flaw. The argument that it isn't part of the "standard Ubuntu experience" shows a disappointing disrespect for users.

Fortunately they still support Gnome. Otherwise I'd be switching distros.

I really like Tim Allen's solution. It is certainly worth trying.

I also agree with Carey Underwood that this should be "wishlist", not "won't fix". Either FFM should be disabled or it should work.

For what is worth, I give a +1 to Lachlan Andrew. Moreover, it is so easy to fix: let the user optionally choose global menu only for maximized windows, local otherwise. In my humble opinion, it would be the best of two worlds.

Now I am forced to move the window to touch the upper bar every time I was to use the menu, or go with keyboard selection, or, but it's suboptimal, run with double menus (local and global --- that's not too bad, but I fear they will drop it).

Testing Kubuntu now, maybe that could be a solution; but this is sad, since I like Unity a lot and it will be perfect with just that little option.

I had a similar problem in windows 7, except that it will allow you to apply the activation delay to focusing a window (I set it to 80ms) which I have not been able to do in linux.

Linux has an activation delay but it seems to only apply to raising a window. If this could be enabled for focusing windows then I can get my mouse to the menu at the top of the screen, passing thru other windows quickly without activating them.

Yes, the delay could be a workaround, but I still find it illogical. I continue to think that having global menu for maximized windows and local menus for un-maximized ones is the logical, and expected, behavior. But well, it seems that we (we = people that like Unity after all) are condemned to have just what Macs thinks it's nice.
Maybe convincing MacOs developers to change their behavior/add a configuration option will do the trick? ;-)

This truly is something worth fixing, and I'm rather surprised to see it discounted as a non-issue and a "wont fix" resolution. It sure seems to me this is something that can be solved in such a way that everyone is happy and without requiring global menus be disabled (though even then it doesn't work right - for example if the mouse is at the edge of two adjacent windows, the mouse pointer will gets confused. For terminal windows, this often means you cannot select text starting at the first column).

Please fix this, thank you!

Another option (that i don't think would be too intrusive) would be to temporarily disable focus-follows-mouse while holding a key (eg. ALT). So if you needed to access a menu for a particular app, you could just hold down ALT while you move you mouse to the menu bar and it would ignore any other window you tracked over. ALT seems like a logical choice since it activates the menus anyway, and I find myself needing to access the menus for non-fullscreen apps rare enough that holding down a key wouldn't seem that much of a pain.

Personally my preference would be for the solution that mpt proposed.

Good news, other people trying to restore their productivity in the face of Unity global menus have found some ways that might allow you to keep using Unity rather than necessarily switching back to Gnome.

  http://www.addictivetips.com/ubuntu-linux-tips/how-to-disable-global-menu-in-ubuntu-11-10-tip/
   Uninstall the global menus: sudo apt-get remove appmenu-gtk3 appmenu-gtk appmenu-qt

  http://www.webupd8.org/2011/03/disable-appmenu-global-menu-in-ubuntu.html
    Set an environment variable: UBUNTU_MENUPROXY=0

Once global menus are out of the way you can restore focus-follows-mouse.

Of course what we would all like is focus-follows-eye, but until then, focus-follows-mouse will keep you from the RSI-inducing task of clicking back and forth between the applications you're using.

Plus you save all those return mouse trips to the top left of the left-most screen every time you need something on an application menu.

What I'd really like to see is global menu only for maximized windows... sloppy of click focus, it would be great (and IMHO the most intuitive option).
But it's marked won't fix --- so I suppose no cigar.

I would be happy with a global key that 'locks' the global menu into place (or equivalently locks focus) allowing me to reach the menu. Something like Alt or the like.

Andres Franceschi [2011-10-15 18:32 -0000]:
> I would be happy with a global key that 'locks' the global menu into
> place (or equivalently locks focus) allowing me to reach the menu.
> Something like Alt or the like.

You can do that -- press Alt+<menu shortcut letter> (the underlined
letter in the menu that appears), then the menu opens and stays.

That's what I'm using to deal with this problem (I can't live without
FFM either)

As of 11.10 editing /etc/X11/Xsession.d/80appmenu and 80appmenu-gtk3 to change UBUNTU_MENUPROXY to 0 works more or less OK. The problem is that it is global setting for all users, and that there is in fact no natural place to set this variable for single user.

Couldn't there be a switch
  [x] Use global menu
somewhere in settings? After all, even click-to-focus users need not like the global menu (especially when they use big screens with many apps)

re #30 - it works for many windows but not all. For example thunderbird still puts its menus up at the top of the screen.

However, doing that edit and using software center to remove all packages that come up when you search for 'appmenu', which is more than what is listed at #26 and includes thunderbird-globalmenu, seems to do the trick (at least, it does for all the things I use).

Incidentally, at #26 - " what we would all like is focus-follows-eye" - most certainly not. That's rather the point of FFM - you can readily have your eyes on one window (the one you're copying out of or referring to) and your input going to another where you might not be looking at it as you type. If you only ever want input going where you're looking, then click-to-focus-and-raise is surely good enough?

I too think "not the default experience" stinks. If that's the attitude why allow anyone any customisation? Is this not betraying an implicit assumption that everyone on the planet wants the same eye-candy, speaks the same language, works the same way, has the same hardware as the developers? Why would you possibly want to change anything from how it installs by default? Surely it's perfect as it is?

And while I'm ranting (and you've got software center open) removing all packages with any reference to 'liboverlay-scrollbar' in their title is a big improvement too...

Hi everyone. I've decided to take some initiative to solve the long list of problems with focus follows mouse in Unity. With this aim, I have created a focus follows mouse team and a PPA to host patched versions of Oneiric packages.

I have looked for an existing effort but not found anything. Please let me know if there is something I should be aware of. Please also let me know if there is some other kind of group I should create to help further this aim.

The team page can be accessed here:

https://launchpad.net/~focus-follows-mouse

Anyone who is interested in helping out with anything relating to focus-follows mouse in unity, please join the team and its mailing list.

I'm posting to this bug for two reasons. Firstly there are a lot of subscribers and it is a good way to look for members for my new team. And secondly, of course, I'd like to do something about this bug and provide updated packages in the team's PPA.

So, suggestions are welcome on what I/we need to do here. My personal view is that disabling the global menu should be easy. I have disabled it myself and this works pretty well for me.

I'd also like to try and implement one or some of the suggestions here for keeping it. From skimming this thread I see the following solutions:

- Show the menu for the highest window (patch included). I don't really like this because it kind of defeats the point of focus-follows mouse. Do other people like this solution?

- Show the menu for the last window to be clicked in. This sounds interesting but I wonder how it would work in practice. It also seems quite close to the way the global menu is designed to be used. I wonder quite how well it would work in practice. I think a certain amount of indication would be needed to make it clear what app has the menu focus. I also think that instead of all clicks changing the menu that we could experiment with other idea.

- Detect a movement directly to the menu and prevent it from changing. This is also interesting, although possibly tricky to implement correctly. If it worked it could be an extremely intuitive solution. That said, intuitive solutions aren't necessarily what people who use focus-follow mouse use. Rather they are looking for the most efficient solution, and this one could get annoying.

If I get some specific feedback with regards to these solutions then I'll put some work in and upload some packages to my PPA.

Hi James,

thanks. I joined the team, although I am not (any more at least) a developer... but I will test and help and comment.

One suggestion: I still think that the best approach to global menu and focus-follow-mouse would be having the global menu only for maximized windows. Heck, it would be logical even for click-to-focus, in my opinion.

What I would like is that when you maximize the window, the menu "shift" on the global menu position --- I asked for maximum space to work with just one app, no? And then when I unmaximize the window, the menu go with it --- all other options in my opinion are quite awkward.

Having the menu on unmaximized windows on the the titlebar would be nice too, provided that a space to grab the bar to move the window is left.

> Show the menu for the last window to be clicked in.

How about including any keyboard activity in the window, since ffm removes the need to click, and we (I) often don't click in one?

> I think a certain amount of indication would be needed to make it clear what app has the menu focus.

Good idea. Maybe just an amplified version of the normal title bar/frame coloring that we already get for the window with focus.

I am not using Unity anymore, so about all I can do is give ideas if I think they are valuable. I hope they are. :)

FWIW i'd like to let my voice be heard here a well. I *really* like unity so far, except for the FFM problems. I'd very much like an option to have the global menu only on maximized windows, which would solve both the FFM behaviour as make my large monitor more usable with small windows.

All the other solutions to the FFM problem seem a bit baroque to me, but maybe they would work better on smallish monitors?

here's a related bug, which deals with unity on big screens (i.e. the global menu is lots of distance away from small app windows on big screens).

https://bugs.launchpad.net/ubuntu/+source/unity/+bug/682788/comments/60

i hacked the appmenu-gtk package for a proof-of-concept: the globalmenu always is shown, but when the app is not maximized, the local (classical) menu is shown additionally.

+ it solves the focus-follows-mouse compatibility issue (i am very dear of sloppy mouse focus myself for ~14 years ;)
+ for big screens it greatly reduces the distances to travel (for apps that still rely on heavy menu use, e.g. inkscape, libreoffice,...)
+ used it the last days, and it seems to integrate well with the rest of the desktop.

- it would need to implemented in appmenu's toolkit packages, i.e. for each toolkit :/ right now i just hacked the gtk bridge, we would at least need patches for QT and mozilla's XUL toolkit for any sensible coherence, still leaving out e.g. libreoffice (but it's not integrated yet anyway)
- how to enable that feature?
i don't think unity will use it as a default (as they don't use sloppy-mouse). we cannot auto-enable it with e.g. sloppy-mouse setting, as there are also other beneficial use cases. the best probably would be a switch somewhere in the gtk system configuration, but i'm not sure how to do this cross-toolkit without introducing a lot of dependencies. dbus? the easiest would be an environment variable (which would e.g. be set in /etc/environment or on login), but then the feature is not very discoverable.

rawphi: This looks really interesting, I will check it out.

As for how to manage the settings. I think the status quo is to have a separate setting in compiz, gtk, kde etc.

Compiz config includes backends which somehow keep all these options in sync, I think. Here's a little bit of info:

http://wiki.compiz.org/CCSM#Backends_and_Integration

I'm sorry of I say something stupid here; I haven't read all posts in this issue, only the topic and issue itself.

I like sloppy focus, I like Unity and its global menu, and I don't like the side effects that activate the wrong window's menu. But I have an suggestion I'd like to discuss.

The idea is actually quite simple: Sloppy focus doesn't give immediate focus to windows, but only gives focus when actual input is sent to that window, e.g. though mouse or keyboard events. Therefore, windows that are hovered by sloppy focus mouse are instead set in a "focus-candiate" state, leaving the focus at the original windows.

In a way, this behaves like "Click to Focus" but also adds "Keypress to Focus Window below Mouse"-like feature.

GUI-wise the focus-candidate windows could be highlighted in a different way, but I think it would be better not to colour them, that is: present them as unfocused windows.

This feature should give the following positive effects:
1) The user can move the mouse from one originally, focused window, across other windows (that will gain focus-candidate), and to the global menu of the originally, focused window as the user intended.
2) The user can move the mouse from one originally, focused window (maybe across several windows) to another target window (that will gain focus-candidate) and start typing or click in this window, and this target window will gain the input as the user intended.

This will give the following potential unwanted issues:
1) Windows with focus-candidate were the application responds to mouse move events (gestures?) will be unresponsive until clicked within the window, on the window title or a keyboard key is pressed. A work-around or work-flow to focus a focus-candidate could be to press Ctrl, Shift, or Alt in order to fire a keyboard event but not to do any "damage" by inputting actual keystrokes in the window. (e.g. pressing Enter in a focus-candidate editor window would leave a line break that one would have to immediate delete afterwards).

Unity with sloppy focus is severely broken - it breaks Eclipse popup-windows (any RCP based product, not just the java IDE) - javadoc, Ctrl+O, Ctrl+F8, Ctrl+3 - all broken if the mouse pointer is in the area the popup window will appear. What happens is that the window appears but is instantly closed, giving you no chance to provide input to that window (mouse or keyboard), nor read anything.
Terribly annoying since the only viable solution is to enable click-to-focus.

From what i've read on this problem the only simple solutions that i see are:

 1. As others have suggested, have an option to show the menu in the window when not maximized.

 2. Give the option to wait a little (200ms - 500ms) before changing focus to another window. This gives plenty of time to move the mouse to the appmenu on the top from any position on a big screen. The focus change delay is so small that it'll be imperceptible for most of the users.

I personally, would prefer option 2.

I vote for option 2 on comment #40, Give the option to wait a little before changing focus to another window.

Gnome-shell uses a "dwell" timeout that works very well for this.

Your mouse has to sit on a window without moving for (iirc) 20 ms. It's long enough that I've never hit it accidentally, but short enough that you almost never notice it.

I'd also like to see this reopened and have issues fixed. To me, having the menus be attached to the windows when not maximized makes the most sense to me. Any time I have multiple apps visible simultaneously, accessing menus is a nuisance.

FFM is a requirement for me. I've been using it for almost 20 years. I know I can enable it on the side, but that's rather sucky.

The "dwell" solution mentioned in #42 seems like it would work fine, although there is another bug requesting the option to turn off global menu in a window that isn't maximised... this would solve the issue also.... there are about 700 people requesting that.

Let me add my voice to the people expecting a modern operating system to send my keys to the window containing my mouse.

I'm starting to understand why people have strong feelings about Unity. "I'll just turn on FFM." "No, you can't do that because you'll never be able to get to your menus.." "WTF???"

Could someone please implement the dwell solution and let it be experimental, e.g. let the option be enabled by set UNITY_MOUSE_FOCUS_DWELL=1 or similar? At least that would be a starting point for some experience and feedback.

... and also my #38 suggestion set UNITY_CLICK_AND_TYPE_TO_FOCUS_WINDOW=1 please ;)

I am still unable to understand why all this could not be solved by leaving an *option* to have the dear, old, clumsy if you want, menu *in* the application window. Ok, I loose 32 vertical pixel; my option, my problem. If I want to go full screen I have other options.

Now that in 14.04 the menu can be again on the top of the windows, this bug becomes more important.

With Focus-follow-mouse activated, it is not possible to rename/delete desktop elements if the desktop is not completely free.

(Millions of linux users use focus follow mouse in their everyday work)

Indy: I'm confused by your comment; I thought menu-in-top-of-window kind of solved this bug; what exactly is it that doesn't work for you with this?

Dave

Dave Gilbert : Indy is right
the f-f-m option sets the focus on the last window visited, and as long as windows are open the desktop never gets the focus. It means it is impossible to rename an icon on the desktop (or you need to open a file browser and open the desktop inside the file browser)
What I don't understand is that this issue would be solved with a very simple variant of focus-follows-mouse :
the behavior should be that
1- it focuses on the window under the mouse
2- it keeps the focus on the last window visited when the pointer is on the desktop
3- it focuses on the desktop if you click on it (and in general on any window you click in, since sometimes some bug makes the focus loose the mouse). In particular, when you click on an icon in the background (or create it) the focus should be automatically transferred to that icon...
currently the behavior is 1+2, but not 3.
to sum up, "focus follow mouse" should be a layer onto "click to focus", not an exclusive option.
this would still allow to visit the upper bar (for the crazy users who disable the menu-in-window feature).
The truth is that f-f-m is so handy that once one has tried it, it is hard to change back. (I first tried it on X-10... hmm, in '91?)

Horrible bug that causes data loss:

1) Open a Nautilus file browser window.
2) Focus a directory or file.
3) Create a file or directory on the desktop, while the Nautilus window is open.
4) Click on the file or directory on the desktop.
5) Press the Delete key on the keyboard to delete the newly selected item on the desktop.
6) RESULT: The selected item in the *Nautilus window* gets deleted!

Please fix sloppy mouse focus on desktop. Please fix it now. It's about time.

There's a remaining issue with FFM: random windows get focus when closing windows or switching workspaces.
Focus should only be changed intentionally, i.e. by moving into a window or clicking in a window.

When closing (hiding/minimizing/sending to other workspace) a window, focus should return to the window that had focus before the now-gone window.

When switching to another workspace, focus should remain with the window that had focus on that workspace.

Relevant bug: https://bugs.launchpad.net/focus-follows-mouse/+bug/958432/comments/2