[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: "Click raise active window" in kwin
From:       Lubos Lunak 7 <l.lunak () suse ! cz>
Date:       2005-10-24 12:33:48
Message-ID: 200510241433.48891.l.lunak () suse ! cz
[Download RAW message or body]

On Wednesday 19 of October 2005 15:19, Chong Yidong wrote:
> Hi,
>
> I'm an Emacs developer, and I'm trying to track down a bad interaction
> between the current CVS version of Emacs and kwin (KDE 3.4.3).  I'm
> hoping someone on this list will be able to help.
>
> The problem is this.  I have "click to focus" and "click raise active
> window" on.  I hover the mouse over one of the Emacs tool-bar buttons,
> making an Emacs tooltip pop up.  Clicking the mouse dismisses the
> tooltip, but does not activate the button.  The problem goes away if I
> turn off "click raise active window".  My guess is that kwin is
> passing the click event to the tooltip, trying to "raise" it.
>
> (These is on a "non-toolkit" Emacs build.  Emacs draws its own
> tooltips instead of relying on an X toolkit).
>
> Could someone explain to me what effect the "click raise active
> window" setting has when "click to focus" is on?  It seems not to
> affect the behavior of the window manager unless using the "mouse
> follow mouse" policy.  The only thing it seems to do is to cause this
> Emacs bug to appear.

 From the user's point of view, "click raise" raises the active window 
everytime you click it, always, regardless of the focus policy (note, active 
window - for inactive there are all the configurable the mouse actions). I 
suppose it makes more sense with mouse focus policies but you can have an 
active window that's not topmost with click to focus too (e.g. MMB on the 
titlebar).

 From the technical point of view, click raise results in KWin having a 
passive mouse button grab on windows where raising on clicking makes sense 
(i.e. no point in having the grab if click raise is turned off or if the 
active window is topmost). It could be Emacs gets confused by the focus 
out/focus in events resulting from the grab (=Emacs bug).

 Thinking of it, it's not "active window is topmost" but "active window is not 
obscured" for avoiding the passive grab, which could be the reason the 
tooltip triggers it. It's not 100.000% correct, but nobody seems to notice ;) 
and it's simpler that way. If you'd feel like trying to change the way KWin 
does it in order to avoid the Emacs bug, just say so and I'll give you some 
pointers to the code.

-- 
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/
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]