New systemtray: beginnings and how to do

[Marco Martin]

On Monday 16 February 2009, Aaron J. Seigo wrote:
> 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.
yes, and fall back at the proper cases, that is the most worrying part, yeah
> 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.

ok, so we don't need a subclass of ksystemtrayicon, but something with roughly 
the same api, i'm going a bit blindly there because i still never looked at 
both KSystemTrayIcon and QSystemTrayIcon

> 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.
hmm, as a name wouldn't confuse  a bit with dbus notification and galago 
things?
> > 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.
ok, so tomorrow i'll move the daemon in workspace together the applet and 
include the systemtray plugin, so to recap as names we have: (that can't come 
up with ones i like for none of them)

SystemTrayDaemon: the kded daemon

DBusSystemTrayTask/DBusSystemTrayProtocol in the system tray applet 
(DBusNotificationTask was already there, so...)

KNotificationIcon the client library

we could come up with a cool name for the specification so we can stick with 
that everywhere, two random ideas
TrayBus (the fancy rather meaningless one)
NotificationIcon (the really (too much?) generic one)

any nicer ideas?

Cheers,
Marco Martin