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

List:       kde-devel
Subject:    Re: Thoughts on the systray II.
From:       LiuCougar <liucougar () gmail ! com>
Date:       2005-04-16 20:34:00
Message-ID: 955806780504161334aeef1c () mail ! gmail ! com
[Download RAW message or body]

On 4/16/05, Aaron J. Seigo <aseigo@kde.org> wrote:
> 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?
I admit the main concern is the former one.

> > > 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.
Then could you enlighten me how can I reparent a qwidget to another
qwidget in another process?

> > > 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.
I do think if there are some heavy procedure in an applet, then it can
implement its own thread if wanted.

Regards,
Cougar

-- 
"People's characters are strengthened through struggle against
difficulties; they are weakened by comfort."
- Old Chinese adage
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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