THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added:
FS#778 - Clients with nofocus hint but with TAKE_FOCUS protocol doesn't hit into focus history User who did this - Uli Schlachter (psychon) ---------- There are four input types: http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.7 When the app got the "input field" set to true, the window manager sets the input focus on the app. If the app says it does WM_TAKE_FOCUS, the window manager sends an event to that app and that one then sets the input focus itself. Both of this are done through SetInputFocus aka xcb_set_input_focus(). Via this, the app can e.g. ignore the offer for the focus hint and not set the focus at all or set it to some totally different window. So much for the X11 stuff. Now for the patch: It makes awesome emit the "focus" signal when it sends the WM_TAKE_FOCUS, even though the app doesn't have the input focus at that time. It's not sure that the app will get the focus at some later point of time since it could ignore the WM_TAKE_FOCUS or do other stuff with it. *If* the app does decide to set the input focus later on, awesome will receive a FocusIn event (event.c, event_handle_focusin()) which results in client_focus_update() to be called. So, whenever the input focus changes, it's pretty much guranteed that the right signal is emitted. Having just written that: What's the problem you are trying to fix? I don't see how any app could avoid being added to the focus history. ---------- More information can be found at the following URL: http://awesome.naquadah.org/bugs/index.php?do=details&task_id=778#comment2226 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. -- To unsubscribe, send mail to [email protected].
