Earlier in this thread, Sam Spilsbury wrote:

> Right, although my question is more a case of "what if a client sets
> the input focus to itself if it specifically requested that it was not
> to be focused"

That generally works, it's just rude.  There is no easy way for the WM to track 
focus and force it where it thinks it should be.  The WM's focus control 
function is more a matter of tracking clicks (click-to-focus) or enter events 
(focus-follows-mouse and variants) and setting focus appropriately.  At least, 
that's my understanding ...

> I suppose this could be replaced with "client updates the WM_HINTS
property" and the WM responds by moving the focus off the client.

There's nothing in the ICCCM that requires a WM to actively monitor the hint 
and respond to changes. The only new protocol you really need would be to add 
that requirement to EHWM.  But if you want to work with any ICCCM-compliant WM, 
 I would be inclined to follow up with an XSetInputFocus to None or PointerRoot 
(with an explicit timestamp), if you really need to lose the focus.  
Unfortunately that's contrary to ICCCM, but probably harmless.  ICCCM does 
cover the situation:

"A convention is also required for clients that want to give up the input 
focus. There is no safe value set for them to set the input focus to; 
therefore, they should ignore input material.

Convention

    Clients should not give up the input focus of their own volition. They 
should ignore input that they receive instead." (Section 4.1.7). 

Giles

                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
  l

-----Original Message-----
From: wm-spec-list-boun...@gnome.org [mailto:wm-spec-list-boun...@gnome.org] On 
Behalf Of Sam Spilsbury
Sent: 26 August 2011 03:48
To: Nathaniel Smith
Cc: wm-spec-list@gnome.org
Subject: Re: Moving the focus off a client window

On Fri, Aug 26, 2011 at 12:26 AM, Nathaniel Smith <n...@pobox.com> wrote:
> 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:
>

Right, although my question is more a case of "what if a client sets
the input focus to itself if it specifically requested that it was not
to be focused"

>>  * 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.
>

I suppose this could be replaced with "client updates the WM_HINTS
property" and the WM responds by moving the focus off the client.

> -- Nathaniel
>



-- 
Sam Spilsbury
_______________________________________________
wm-spec-list mailing list
wm-spec-list@gnome.org
http://mail.gnome.org/mailman/listinfo/wm-spec-list
_______________________________________________
wm-spec-list mailing list
wm-spec-list@gnome.org
http://mail.gnome.org/mailman/listinfo/wm-spec-list

Reply via email to