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

List:       kde-panel-devel
Subject:    Re: [Nepomuk] Nepomukcontroller rewritten in QML
From:       Sebastian =?ISO-8859-1?Q?K=FCgler?= <sebas () kde ! org>
Date:       2013-03-25 13:43:39
Message-ID: 13948842.Gt948BBXFL () miro ! vizzzion ! net
[Download RAW message or body]

On Wednesday, March 20, 2013 20:55:02 J=F6rg Ehrichs wrote:
> > IMHO all of these need to be replaced with the async variants. This
> > unfortunately affects a lot of your code. The service job should be
> > easy as you don't wait for the results, the service engine is less of
> > any easy change. You might want to get a second opinion before
> > starting.
> =

> I was hoping that it could stay this way (less code this way around)
> but ideally you are right, this should go async in case one of the
> services hangs in such a method (doubt that happens, but
> we never know).
> =

> But I'll wait for 1-2 more opinions on this first.

These things should really be async.

Especially if there can be multiple services that you have no control about=
, =

they will hang at some point, and then your UI is blocked -- never a good =

thing.

We've had a non-funny amount of UI problems due to sync calls across IPC, o=
r =

into Nepomuk (and sometimes both), and it gets you a blocking UI, and it =

really deteriorate the user experience. =


In case you're wondering, in Plasma, we're aiming at 60 FPS, that means in =
any =

given method, you may block for at *MOST* 16.6ms, not a lot of time at all.

Cheers,
-- =

sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[prev in list] [next in list] [prev in thread] [next in thread]