When doing a keyboard shortcut for a non-interactive program, the active window should keep its focus. What happens instead: The active window looses its focus for a short time. This is annoying if you are for example playing Gnome Mines and adjust the sound volume using a shortcut for 'aumix -v-5', the game will loose focus and in consequence go to pause mode. Shortly after it will retrieve focus, but stay in pause mode.
It's not a "focus" grab, it's a key/pointer grab and the apps should handle that gracefully, if gnome-mies doesn't, then I am tempted to say its a gnome-mine bug. The window manager (xfwm4) does not manage the shortcuts to launch apps, so this is not a window manager issue.
Just checked, it's not loosing focus, gnomines is reacting to the active grab, not something we could fix in xfce as it's how keyboard shortcuts work, by using active grabs (even less in xfwm4 as it's unrelated), if anything this should be brought to gnomines (although I think this would be seen as a gnomines feature). Anyway, closing as "WONTFIX".
You're right, this also happens with gnome desktop. I will file a bug for gnomine.
*** Bug 7690 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > *** Bug 7690 has been marked as a duplicate of this bug. *** Hello, I am the reporter of bug #7690, which was marked as a duplicate of this bug. You say that this shouldn't be fixed in the window-manager, but rather in the application. I assume you mean that (like in the linked ubuntu bug report in bug #7690) that the application should ignore 'FocusOut' events which have 'NotifyGrab' set. I did some more digging, and I respectfully disagree, and I will explain why. In my case the application is a py-gtk app, and hence relies on GTK+ for proper processing of focus events. All the application does is connect to the 'focus-out-event' and react to that. The handler for this event (in pygtk) looks like this: ---8<--------- def on_window_losefocus(self, window, event): """Hides terminal main window when it loses the focus and if the window_losefocus gconf variable is True. """ if self.disable_losefocus_hiding or self.showing_context_menu: return value = self.client.get_bool(KEY('/general/window_losefocus')) visible = window.get_property('visible') if value and visible: self.losefocus_time = \ gtk.gdk.x11_get_server_time(self.window.window) self.hide() --->8--------- The only thing which could possibly be of use to this function (in order to determine the 'type' of focus event is 'event'. Looking up the definition of 'focus-out-event' we see that event is a Gdk.EventFocus (http://developer.gnome.org/gdk/stable/gdk-Event-Structures.html#GdkEventFocus), which does not seem to contain the information necessary to determine the originating type of 'FocusEvent' (e.g. whether or not it had 'NotifyGrab' set). Looking at the documentation at http://developer.gnome.org/gtk/2.24/GtkWidget.html#GtkWidget-focus-out-event I do see some other 'grab-*' events, however it is unclear to me whether these would allow to solve the issue (I think not). Therefore I don't think that it is possible to 'fix' guake-terminal, or indeed GTK+ applications in general. After-all, these applications rely on GTK+ to send 'correct' events. So can we please agree that this is indeed a bug, even if it is not directly related to XFCE? However since XFCE (seems to me) to be tied quite closely to GTK+, I would like to request that an upstream bug be filed against GTK+, and that this one is then made to depend on that one?
What you describe seems to be in line with the documentation, so to me it looks like the expected behavior and I see no bug here. Yet, I could be wrong, so to convince me, I would require a simple reproducer program (a simple py-gtk example which exhibits the problem would do). A simple start would be to test that reproducer program with various other window managers, including GNOME and KDE to see if it behaves differently there. If it is a bug with xfwm4, then sure, it's the right place to report it and I shall possibly investigate the problem at the xfwm4 level. But if this is not a bug with xfwm4, I am not going to open a bug with GTK+. If you think it's a bug with GTK+ you should report the bug and follow up with GTK+ devs yourself.
Update: I installed guake and can reproduce the described behavior, and it does the same with metacity and kwin as well which, as stated previously rules out a problem with the window manager (it's really an application issue, the window manager has nothing to do with that).
(In reply to comment #7) > Update: I installed guake and can reproduce the described behavior, and it does > the same with metacity and kwin as well which, as stated previously rules out a > problem with the window manager (it's really an application issue, the window > manager has nothing to do with that). Ok, since you are sure that there is nothing xfce can do about it, and I don't particularly feel like taking this up with gtk, I've come up with a work around. Incidentally this may actually be the better way to deal with this anyway, because it looks like the shortcuts also don't work when xscreensaver is active and has the screen locked (this would have become another bug report). The better solution is to use acpi-events (if you can). On my laptop the volume keys also generate acpi events (e.g. button/mute, button/volumeup). I catch those and execute a custom bash-script. By using acpi events I can still control the volume even if the screensaver is locked, and it gets even better: because I'm executing a custom bash-script I can use more complicated commands to fine tune exactly what happens when I press a button. This is the script I'm using now: ---8<--------- #!/bin/sh case ${2} in VOLUP) amixer sget Master | grep '\[off]' && amixer set Master on || amixer set Master 5%+ ;; VOLDN) amixer sget Master | grep '\[off]' && amixer set Master on || amixer set Master 5%- ;; MUTE) amixer set Master off ;; esac exit 0 --->8--------- The 'more complicated commands' are the ones on VOLUP and VOLDN, using pipes and logical operators. These are impossible to use in the xfce-shortcut handler because: - They won't get executed (1), - After the first attempt at execution ALL shortcuts stop working. The only way I found to get shortcuts to work again is to log out/in (2). Thank you for your time and comments anyway. p.s. (1) and (2) should probably be filed as seperate bugs too.