> The advantage of a DBus API is simple: we could make it a freedesktop > standard and share interfaces with systems like Zeitgeit.
Yes, that is my idea as well, but still, accessing the dbus api via a higher-layer class makes it easier to change the dbus api as needed (until it becomes fdo standard, and maybe even later) without changing every program that uses it. An example can be the recent addition of application /name/ to the parameters list when opening a document. *1* KActivity* (client) API remained the same while the d-bus interface was changed. The classes are like small wrappers which allow the dbus api to be minimal and change if needed while providing a nice experience for the developer (sine aKademy, I'm practicing my marketing-speak :) ) Cheerio *1* The d-bus api can't be expected to be stable at this point in development, and we need to start patching apps to support activities now -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
