JaSauders, when a window opens or asks for focus, the window manager has to decide whether focusing it is a good idea.
If you choose an item in an indicator menu, wanting to see a particular window, obviously it should be focused, right? Well, no. For example, when I choose the date item in the clock menu, Evolution takes 31 seconds to launch and open its window. If I get bored and continue typing this comment in Firefox in the meantime, I don't want the Evolution window to be focused when it eventually opens, because that would mean some of my typing would go into the wrong window. So, a window should be focused if you don't do anything -- or you aren't *about to* do anything -- between the time you ask for it and the time it opens. Simple enough, right? Well, no. Because the window manager usually doesn't know (A) exactly what action of yours -- if any -- caused the window to open in the first place, or (B) whether you are about to do something. (It can't see your finger getting ready to press a key, for example.) The fixes for this bug address (A), by including the timestamp of your menu selection with the request to launch a particular app. But sometimes that isn't possible, often it isn't supplied even when it is possible, and either way, that still doesn't address (B). So the focus-prevention-level setting is a dial for how eager the window manager should be in granting focus requests. The higher it is, the more often you'll get focus sticking -- a window failing to take focus when you expect it to. But the lower it is, the more often you'll get focus stealing -- one window taking focus while you are trying to use another. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unity in Ubuntu. https://bugs.launchpad.net/bugs/627195 Title: Window management - Apps raised from indicators sometimes dont have the focus Status in Ayatana Design: Fix Committed Status in Compiz: Invalid Status in The Messaging Menu: Fix Released Status in Messaging Menu 13.04 series: Fix Released Status in Sound Menu: Fix Released Status in The Sound Menu 13.04 series: Fix Released Status in DBus Menu: Triaged Status in MPRIS D-Bus Interface Specification: Confirmed Status in Ubuntu One Client: Fix Committed Status in Unity: Invalid Status in compiz package in Ubuntu: Invalid Status in empathy package in Ubuntu: Fix Released Status in indicator-messages package in Ubuntu: Fix Released Status in indicator-sound package in Ubuntu: Fix Released Status in libdbusmenu package in Ubuntu: Confirmed Status in tomboy package in Ubuntu: Confirmed Status in ubuntuone-client package in Ubuntu: Fix Released Status in unity package in Ubuntu: Invalid Bug description: Ubuntu 11.10 beta compiz 1:0.9.5.94+bzr2803-0ubuntu5 unity 4.16.0-0ubuntu1 1. open banshee, start a song in it and minimize 2. open another application lets say gnome-terminal 3. click on the sound menu and select banshee What happens banshee icon in the launcher wiggles and banshee main window is not shown What should happen banshee main window should come to focus This is a long standing bug which Ted Gould thinks should be fixed at window manager's level. ====Some other observations===== The problem wont happen 1. if every other app is minimized or 2. Banshee is the only opened app or 3. after opening gnome-terminal, banshee window is closed so that it hides to the SoundMenu and opened again =====Comment from Ted Gould===== <om26er> tedg, Hi! any thoughts on the long standing bug 627195 ? Its been there before unity so I guess we can conclude unity not to be responsible <tedg> om26er, My thought is that window managers should $%#$ get fixed... though I haven't convinced smspillaz of it yet. =====The good rule===== 3v1n0: Indicators should present the application windows by passing to them the timestamp of the menu item activation event. Unfortunately for indicator-sound, this is not trival as it sounds, since it needs a change to the MPRIS dbus specification. See comment https://bugs.launchpad.net/ayatana-design/+bug/627195/comments/26 for more informations. For what concerns libappindicator based indicators (such as the one used by tomboy), since it's not currently possible in libdbusmenu to pass the event during activation (so that clients will be able to get the proper timestamp using gtk_get_current_event_time), there are two "hackish" ways: 1. Use the server time to present a window: https://bugzilla.gnome.org/show_bug.cgi?id=688830 2. Get the event timestamp from the dbus-menu linked to the gtk-menus: http://paste.ubuntu.com/5701235/ 3. Qt applications workaround: http://is.gd/WnW9eN Window managers will obey to it. To manage notifications about this bug go to: https://bugs.launchpad.net/ayatana-design/+bug/627195/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
