On Wed, Aug 24, 2011 at 11:06 PM, Sam Spilsbury <smspil...@gmail.com> wrote: > I'd like to be able to have some kind of protocol to handle this case, > and initially I thought that maybe I could change the input hint on > the client window to FALSE and then send a synthetic FocusIn event to > the client window, at which point the window manager would receive > that and move the focus off to something else since that window is not > allowed to be focussed. However, the ICCCM is vague on this point, and > says that where WM_TAKE_FOCUS is not present in WM_PROTOCOLS and > InputHint is FALSE in WM_HINTS then the window has "No Input - The > client never expects keyboard input. An example would be xload or > another output-only client. ". However, it does not state what should > happen should the client explicitly request input focus, which is what > is going on here. I would imagine in this case that should a client > request input focus to a window that does not allow input, that the > window manager should focus the next appropriate window, whether that > be a transient window, an ancestor, a group member or the next most > active window. > > What does everyone think of something like the following: > > * Client changes InputHint to false and removes WM_TAKE_FOCUS from > WM_PROTOCOLS
It seems to me that this should be sufficient -- just clarify the spec to make sure it's clear that a window can transition from focusable to not-focusable. I don't see what the stuff below adds: > * Client sends a synthetic FocusIn event to its own window with the > window member being set to the client, mode being NotifyNormal and > detail being NotifyDetailNone > * WM gets the FocusIn event on the client window, sees that InputHint > is false, moves the focus off to the next appropriate window. -- Nathaniel _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list
