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

List:       kde-core-devel
Subject:    Re: KWin locks KDE with Alt+Tab
From:       Matthias Ettrich <ettrich () trolltech ! com>
Date:       2001-06-28 12:25:52
[Download RAW message or body]

On Thursday 28 June 2001 00:46, David Faure wrote:
> On Tuesday 19 June 2001 15:21, David Faure wrote:
> > > Do you still get these locks with the taskbar after my commit from
> > > yesterday? Harri had the same problem on his laptop but cannot
> > > reproduce it anymore.
> >
> > Ah, I thought this was only related to Alt+Tab....
> > I wanted to keep kdelibs-2.1.2 on the laptop (to test koffice with it),
> > but I'll upgrade to see if this fixes it, then.
>
> Hmm, no luck. I updated kdelibs & kdebase on the laptop.... ouch, not
> better, maybe even worse.
> I don't think the problem is only Alt+Tab and its grabbing.
> With simply two windows opened (a konsole and an xemacs, or even two
> xterms!), if I click inside the one of the windows => the mouse pointer is
> 'stuck' to its current shape and won't change, whatever I do with it.
> So this looks like some "focus" problem...
> Either kwin or X......
>
> Hmm, just tried kwin from KDE 2.0 ... same problem.
> Then I tried kwm (KDE-1.1.2)... _no_ problem.
>
> So... long standing kwin bug ?
> How can I debug this ?

Tough to say, I don't know. The problem is clearly related to the way kwin
does XGrabButton (to install a passive grab over the window wrapper) and
XUngrabButton afterwards ( to release the passive grab, in the function
ungrabButton() in client.cpp ). And of course the XAllowEvents to release the
queued device. This is all in client.cpp.

We need to compare that to the way kwm handled it.

For debugging: It would be good to know whether we at least receive the
ButtonPress event in WindowWrapper::x11Event().

I assume the freezing happens when you click on an inactive window?

Matthias

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