Bring some KDE / Ubuntu to the System Status Area?
- From: Giovanni Campagna <scampa giovanni gmail com>
- To: Gnome Shell List <gnome-shell-list gnome org>
- Subject: Bring some KDE / Ubuntu to the System Status Area?
- Date: Thu, 24 Jun 2010 01:41:13 +0200
After all discussion raised on bug 622451 (the experimental power
manager applet). I was thinking if it was appropriate for the shell to
implement KDE's and Ubuntu's (Ayatana) protocols for system tray /
system status. The KDE part is concerned with getting icons, tooltips
and managing attention, while the Ubuntu part is about transmitting a
set of GtkActions over DBus.
I was thinking of this because:
- it would allow us to deprecate existing XEmbed system, not just
putting everything down into the message tray
- would get compatibility with KDE apps inside GNOME
- would get those components out of process, without bloating core GNOME Shell
- would require no modification to existing gnome-power-manager /
gnome-bluetooth (or actually, would require getting back upstream the
Ubuntu patches)
- would get compatibility for a new nm-applet (to be written) inside
the old GNOME Panel + IndicatorApplet
KDE's and Ubuntu's effort were mentioned in discussion of power
manager applet, but rejected saying that KDE's part (not Ayatana
protocol) is too tied to Plasma. Having read the protocol, I see some
KDE specificity (the separation between the watcher, kded, and the
host, plasma, to get statistics and allow the user to hide the icons
he doesn't like), but it is secondary (and maybe also useful in the
context of GNOME). The main point of KDE protocol is exposing an icon,
composed of a title (tooltip), 3 Icons (active, attention, normal) and
an associated window (another KDE specificity, as they plan to merge
the system tray with the task bar). I don't think it is too bad.
I could not find official documentation for Ayatana dbusmenu
interface, unfortunately. But from rapid reverse engineering I saw
that provided indicators (say, sound) have the
org.kde.StatusNotifierItem stuff, some /org/ayatana/indicator/* stuff
for saying that this indicator exposes a menu,
/org/ayatana/indicator/*/menu is the menu itself and
/org/ayatana/indicator/*/service is an object that provides
functionality specific to that indicator (like a common DBus interface
for lowering volume - without messing with PulseAudio or ALSA)
As I see that rewriting some basic UI in JS on top of data providers
(NetworkManager, UPower...) is not the way forward for GNOME Shell, I
could start implementing the system tray part of the protocol using
Shell API and St, so that menus and buttons get all functionality and
integration of their JS equivalence, while remaining out of process
and git tree.
But since this may require a lot of work, maybe across the whole
summer, I am going to start it only if it really worth it, that is,
only if it could make it way inside GNOME 3.
Regards,
Giovanni Campagna
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]