On Tuesday 26 May 2009, Ivan Čukić wrote: > Hi all > > Just joking about SoK, but while we are in freeze, I'd like to start the > discussion about D-Bus interface for plasma-desktop. > > >From my point of view, we should have the following: > > - desktop locked state - setters / getters / signals > - activities > - current activity set/get/signal
what would the signal be for? > - add activity (+signal?), remove activity (+signal?) > - containment handling > - listing, adding (? + signal?), removing > - applets > - listing, adding to containment (? + signal?), removing specific > applet - removing all applets of a certain type i don't think the signals are necessary, but the rest if good, yes. > - data engines access? this probably doesn't belong with the plasma-desktop dbus stuff (as that would incur a runtime dependency on plasma-desktop for apps, so isn't overly useful), but running dataengines OOP as a general thing would be an interesting project indeed. one would hope it would make the UI a little snappier in some cases, though it certainly would mean more CPU usage and memory usage due to having two processes and some IPC traffic. -- 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 Software
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel