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

List:       kde-devel
Subject:    Re: Get global X events and save your environment!
From:       Lubos Lunak <l.lunak () suse ! cz>
Date:       2007-07-12 13:04:45
Message-ID: 200707121504.45328.l.lunak () suse ! cz
[Download RAW message or body]

On Sunday 08 of July 2007, Stefan Kombrink wrote:
> On Saturday 07 July 2007 15:45:42 Lubos Lunak wrote:
> >  I don't think the code should use threads, because, in the first place,
> > it actually doesn't need them, as there's nothing blocking; another
> > reason is that one should call XInitThreads() for that to work, which
> > generally does not really work and causes all kinds of problems.
>
> Isn't the XNextEvent blocking?

 XNextEvent() can be blocking, but only if there's no event to process.

> Anyways one would need an ClientMessage to quit the thread.
> Can you think of a way to do the XEvie stuff without a QThread?

 I don't see any need for even a separate X connection. Just use the global 
one used by Qt and filter out the relevant events in some X11 filter event 
function (e.g. KApplication::installX11EventFilter()).

> >  Yes, it would be nice to have a shared implementation for this.
> > Especially the copy&paste is pretty bad :(. I just don't think it should
> > use Xevie - it should use the code that kdesktop has, plus (very) recent
> > X.org has an XSync counter that can be used to detect user inactivity.
> > Which should be sufficient for all the cases listed above, except for
> > KSynaptics, if I'm getting it right :-/.
>
> What kind of mechanism does kdesktop use?
> Is it possible to catch key events in idle mode using XSync?
> I got no idea how the XSync stuff works. I once read the documentation and
> felt like it would be necessary to modify XOrg? (like predefined event
> counter or something like that)
> If that is possible I'd immediately agree to use that.

 As I said, all those mechanism would work for everything except for you - 
they don't track key events per se, it just tries to find out user 
inactivity. Which is what kdesktop/screensaver, kopete etc. need, they don't 
care what's the cause of the user activity.

 If you want to really catch key events, I don't see any other option than 
XEvie, but for the others that seems to be a bit of an overkill.

> Also agreed: In my use cases you get away with (in)activity detection, but
> the follow-up from KDE usability shows that there are other use cases as
> well

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak@suse.cz , l.lunak@kde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
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]