4.5 - Activities

[Aaron J. Seigo]

On March 26, 2010, Ivan Čukić wrote:
>  - all manager signals converted into listener objects

this is the registeredActivityControllers stuff in the kded service? if so: 
turns out that dbus signals aren't as bad as i had been led to believe. it 
turns out that some of kdelibs were using certain dbus signals poorly which 
was resulting in the "every process is waking up" behaviour. this had been 
blamed on dbus signals by some, but turned out not to be the case. i still 
think that registering controlers in this manner is "the way to go" though, as 
it will make it far easier to debug issues with multiple controllers, give us 
the option of controlling who can control and when in the future, etc.

>  - consumer signals left as is (they are not invoked that often, and are
>    something most applications should respond to eventually)

as noted above, this is even a moot point now that we know that dbus signals 
are indeed more discretionary. :)

>  - changed d-bus API to fit the style of other KDE services

looks good

>  - added test shell script for nepomuk service
>  - added test implementation of a manager application

tests ftw!

>  - added location resource type
>  - changed a LOT of API

can we get together on irc soon and do a once-over of this and then get it 
moved into kdereview?  

> I need to do some more testing, but this should work well enough (TM)
> for other parts (UI) to be developed.
> 
> I've still retained the kded service <-> nepomuk service organization
> for the before mentioned reasons, including another (IMO) important
> one:
>  - the present packaging of nepomuk is easily breakable (I don't want
> to say that Nepomuk itself is not stable, but that installations of it
> are :) )

then it's an installation issue, and not our concern (at the code level)

> and while, for example, Akonadi can show a message like "blah
> blah not available, akonadi-based apps are not usable", we
> (Plasma/KWin) don't have that luxury.

activities are not a required feature.

> After the time comes when we can rely on nepomuk 24/7, we can remove
> the caching kded service since all of this is hidden behind the API.

if we work around subsystems because "they don't work well yet" then the odds 
they ever will work well goes down as there is less reason / motivation to get 
them working well. if those subsystems can't be made to work well, then we 
shouldn't have them in our stack. otherwise, the aim should be to make them 
work. it's that simple. please stop working around brokenness.

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

KDE core developer sponsored by Qt Development Frameworks