Re: TAKE_ACTIVITY patch

[Lubos Lunak <l lunak suse cz>]

On Sunday 03 of October 2004 20:41, Elijah Newren wrote:
> On Sun, 03 Oct 2004 13:50:57 -0400, Havoc Pennington <hp redhat com> wrote:
> > It seems more important to say that the WM must pass through the button
> > release than to say the client has to wait for it.
>
> I don't follow.  I tried writing a workaround which would emulate this
> behavior for clients that didn't support this spec within the window
> manager.  In no case did the WM ever get a ButtonRelease event, and I
> wasn't able to figure out how to get the WM to obtain one (well, I
> guess I could have grabbed, but I was worried that might break the
> client apps).  Others appear to have tried to get a ButtonRelease
> before as well, reading through Gnome bugzilla...

 I think the client which gets a ButtonPress gets some kind of a grab and will 
always get the matching ButtonRelease. I'm not sure how exactly this stuff 
works, I don't know if it's specified somewhere.

>
>
> Also, this spec seems to only mention that it's used for avoiding
> raising a client.  I believe it would be useful to state that it is
> used for avoiding both raising and focusing a client.  It doesn't seem
> to make sense to explicitly focus the app unless we raise it, and

 The proposal doesn't mention focusing at all.

> there is a case in Gnome where avoiding focus is useful and raising is
> irrelevant:  We would like to avoid giving the panel ("taskbar") focus
> when the user clicks on it in most circumstances, but we have to in
> order for certain applets (command line and dictionary ones for
> example) to work.  It would be great to be able to use this spec to
> have the panel only send take-activity responses in the cases where
> focus is necessary.

 Isn't this more for the WM_TAKE_FOCUS protocol from ICCCM (globally active 
input)? This proposal actually was based on WM_TAKE_FOCUS (and WM_TAKE_FOCUS 
was found insufficient for the don't-raise-on-DND problem).

 KWin and Kicker actually solve the problem differently. KWin doesn't allow 
focusing _NET_WM_DOCK windows, unless they request so using 
_NET_ACTIVE_WINDOW message. So if the command-line applet needs focus, it 
simply asks the WM to activate the panel, otherwise the currently active 
window is not changed when one clicks on the panel. I'm right now not quite 
sure how clean solution this is, but it's been there since ages, and Kicker 
is much nicer to use than other panels.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l lunak suse cz , l lunak kde org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/