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

List:       kde-devel
Subject:    Re: Thoughts on the systray II.
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2005-04-16 18:47:20
Message-ID: 200504161247.35680.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Saturday 16 April 2005 12:08, LiuCougar wrote:
> currently, the applet communicates with skim using dcop and it
> contains several dcop signals/slots,

was it designed this way for flexibility, or to keep the actual work in it's 
own process to avoid blocking the UI? if the latter, would it make sense to 
use threads here?

> > it could be either. you could launch a new process or create a window in
> > the same process.
>
> I assumed that the "reparent" window referred to QWidget::reparent(),

yes, that's what i was originally refering to. it would be an easy way to get 
a floating input window.

> > this would be highly limited in capability unless we use XEmbed which is
> > not something i'm interested in doing.
>
> Then in your proposal, applet is still a part of kicker process, right?

yes. kicker really needs to be able to work with the applets directly.

the only downside to this is GUI responsiveness due to having so much 
happening in the same event loop. usually this isn't much of an issue since 
most applets just sit there waiting for user input. but when you get a lot of 
applets in a bunch of panels you can sometimes see the effects of this 
design. but there are even common cases, such as launching an application, 
that can trigger event loop pauses that make the GUI unresponsive.

i've started to look at using threads determine if it is at all practical or 
beneficial. unfortunately even in Qt4 you can only have one GUI thread which 
removes some possibilities (e.g. running each applet in its own thread) ... 
but we'll see. i'm thinking that at least it should be possible to put things 
like the app launching and other non-GUI but potentially pause-inducing 
actions into one or more threads.

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

[Attachment #5 (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


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