Issue 324 in xmonad: Actions.UpdateFocus only works on terminals, not qt/gtk/etc

Status: New Owner: ---- New issue 324 by OrbisVicis: Actions.UpdateFocus only works on terminals, not qt/gtk/etc http://code.google.com/p/xmonad/issues/detail?id=324 What steps will reproduce the problem? 1. XMonad 0.9 and use XMonad.Actions.UpdateFocus as in the documentation 2. Open windows on two different WorkSpaces and tab 3. Switch between WorkSpaces What is the expected output? What do you see instead? If the mouse lands on a gtk/qt/etc window, wiggling it will not update the focus. I tested with firefox,gedit,agave,lyx -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

Updates: Status: Accepted Labels: Component-Contrib Type-Defect Comment #1 on issue 324 by byorgey: Actions.UpdateFocus only works on terminals, not qt/gtk/etc http://code.google.com/p/xmonad/issues/detail?id=324 I can reproduce this, looks like a bug in UpdateFocus. Unfortunately I don't understand how UpdateFocus works well enough to have an idea of what is wrong. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

Comment #2 on issue 324 by liskni.si: Actions.UpdateFocus only works on terminals, not qt/gtk/etc http://code.google.com/p/xmonad/issues/detail?id=324 The problem here is that if a window is interested in its MotionEvents, or prohibits propagation of these events, xmonad does not see them. Citing from http://tronche.com/gui/x/xlib/events/keyboard-pointer/keyboard-pointer.html: The source of the event is the viewable window that the pointer is in. The window used by the X server to report these events depends on the window's position in the window hierarchy and whether any intervening window prohibits the generation of these events. Starting with the source window, the X server searches up the window hierarchy until it locates the first window specified by a client as having an interest in these events. If one of the intervening windows has its do-not-propagate-mask set to prohibit generation of the event type, the events of those types will be suppressed. Clients can modify the actual window used for reporting by performing active grabs and, in the case of keyboard events, by using the focus window. I have no idea how to solve this properly, as listening for motion events on the focused window itself will fix it only if the application listens on its main window as well. If the application listens for motion events on a child window, we'd have to listen on it as well. It is beyond my Xlib knowledge whether this can be done differently. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
participants (1)
-
codesite-noreply@google.com