On Sunday 15 February 2009, Marco Martin wrote: > this basic thing works fairly well by now, what is totally missing of > course is the big part, the comunication infrastructure with the app (don't
how to do this is going to be the big trick in all of this. the d-bus interaction is actually pretty simple, but preserving backwards compat will be interesting to accomplish. we have KSystemTrayIcon which IsA QSystemTrayIcon. so even if we implement the D-Bus protocol in KSystemTrayIcon, we'll always have a QSystemTrayIcon, and therefore a regular system tray icon, as well. what we really want is an API that takes the various possible information (icon, name, tooltip, etc, etc) and internally decides whether or not to use the D-Bus route or to use a KSystemTrayIcon internally and provide the other fun bits (e.g. the tooltip) "manually". so this seems to indicate that we probably want a new class that will eventually end up in libkdeui. it should have a name that doesn't include "SystemTray" in it, and it should be source compatible as much as possible with KSystemTrayIcon so that it can be used as a drop-in replacement or as close to a drop-in as possible. KNotificationIcon? meh. > so what would need to go in workspace would be the daemon and the protocol that's cool with me. for now, let's put the kded plugin in with the systemtray widget. when it gets accepted as an official KDE bit, we can move it somwhere else, though i think it should remain in workspace and only get started when a KDE desktop session is being started. -- 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
