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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel