Re: Moving the focus off a client window

["hannes janetzek gmail com" <hannes janetzek googlemail com>]

On Sat, Aug 27, 2011 at 12:02 AM, hannes janetzek gmail com
<hannes janetzek googlemail com> wrote:
> On Thu, Aug 25, 2011 at 8:06 AM, Sam Spilsbury <smspillaz gmail com> wrote:
>> Hi,
>>
>> I was doing some work on Unity the other day and noticed an
>> interesting problem - we have a situation where we need to keep a
>> window mapped but at some points remove its input shape or move it
>> offscreen. At this point, it makes no sense for that window to keep
>> the input focus, but it doesn't seem like there's a model in the ICCCM
>> or EWMH for handling the case where a client wants to remove its input
>> focus without explicitly setting the input focus to something else
>> (which is wrong).
>>
>
> If I understood correctly you want to make a window make itself
> invisible and take no focus while keeping it mapped. Why not reparent
> the window in the beginning and then just map/unmap the parent?
>

ah I guess you meant it should stay mapped as top-level window to be
visible for the compositor..


> Regards,
> Hannes
>
>> 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
>>  * 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.
>>
>> Regards,
>>
>> Sam
>>
>> --
>> Sam Spilsbury
>> _______________________________________________
>> wm-spec-list mailing list
>> wm-spec-list gnome org
>> http://mail.gnome.org/mailman/listinfo/wm-spec-list
>>
>