Created attachment 165331 [details] [review]
[AppIndicator] Part one: the tray

This commit adds a tray based on KDE/Ayatana/proposed Freedesktop
protocol for renewed tray comunication. Icons following this protocol
support menus, titles and tooltips, as well as providing status and
category, thus allowing seamless integration in the desktop shell, be
it KDE Plasma, GNOME 2 Panel or GNOME 3 Shell.

Created attachment 165332 [details] [review]
[AppIndicator] Part two: menus over DBus

This patch implements DBusMenu, a protocol for describing menus over
DBus, so that application using indicators can have a menu rendered
in native shell look and feel for exposing their actions and UI.
It does not depend on any existing dbusmenu implementation, rewriting
the DBus interface from scratch, to better fit the requirements of
PopupMenu API. Instead depends on bug 622730, bug 623498, bug 621880.

(In reply to comment #0)
> After submitting two experimental system status indicators, network and
> battery, I understood from comments that reimplementing UI inside the shell is
> not the way forward, both practically and architecturally.

I don't think that's true; Richard sort of went on a big rant in that other bug, but the approach of 

> So I needed a way to transfer an UI description from the application to the
> shell, 

Let's keep terminology clear here; we aren't interested in *applications* putting user interfaces here.  This is a possible approach for more directly sharing code with GNOME 2 desktop infrastructure.

> I had already proposed this on the mailing list, and the answer had been that
> such specifications are not fit for the shell design, but I am stubborn and
> decided to see myself.

Heh =)

> So I implemented both specifications, and tested both
> gnome-power-manager and gnome-bluetooth.
> The result, also compared to the power indicator in pure JS, is pretty good, I
> believe, so even if a new spec will be developed for some indicators, I think
> it works as a general fallback solution and it is worth integrating it in
> master.

Hmm...I'm not necessarily opposed to the Ubuntu one, but I'd pretty strongly prefer adding DBus interfaces for power.  It'd be even cleaner if we split out the actual UI for GNOME 2 into a consumer of that DBus interface too.

> (BTW, I don't believe we need ad-hoc solution, and thus I am planning to port
> the only missing component, nm-applet, to libappindicator soon).

NetworkManager is not easy - it uses a lot of hacks to appear as a regular GtkMenu.

(In reply to comment #3)
> (In reply to comment #0)
> > After submitting two experimental system status indicators, network and
> > battery, I understood from comments that reimplementing UI inside the shell is
> > not the way forward, both practically and architecturally.
> 
> I don't think that's true; Richard sort of went on a big rant in that other
> bug, but the approach of 
> 
> > So I needed a way to transfer an UI description from the application to the
> > shell, 
> 
> Let's keep terminology clear here; we aren't interested in *applications*
> putting user interfaces here.  This is a possible approach for more directly
> sharing code with GNOME 2 desktop infrastructure.

Or rather, making GNOME system indicator more desktop-agnostic, given that Ubuntu-ish GNOME 2 supports this, KDE 4.6 is planning to include it and some work is discussed for LXDE and Xfce

> > I had already proposed this on the mailing list, and the answer had been that
> > such specifications are not fit for the shell design, but I am stubborn and
> > decided to see myself.
> 
> Heh =)
 
And you yet have to convince me that this approach is not good, as it saves a lot of code (and less code means less bugs) both on the Shell and inside g-p-m, gnome-bluetooth, nm-applet, ibus, etc., expecially given that libappindicator goes a long way to make indicators just use a plain GtkMenu

> > So I implemented both specifications, and tested both
> > gnome-power-manager and gnome-bluetooth.
> > The result, also compared to the power indicator in pure JS, is pretty good, I
> > believe, so even if a new spec will be developed for some indicators, I think
> > it works as a general fallback solution and it is worth integrating it in
> > master.
> 
> Hmm...I'm not necessarily opposed to the Ubuntu one, but I'd pretty strongly
> prefer adding DBus interfaces for power.  It'd be even cleaner if we split out
> the actual UI for GNOME 2 into a consumer of that DBus interface too.

Doesn't that also mean new interfaces for network, bluetooth, keyboard layout, accessibility, volume...?
Also, doesn't that preclude any additional indicators that still fits the requirements for System, without installing an extension to the Shell (given that GtkStatusIcons are moving down to the tray)? To me, this looks much like a monolith.

> > (BTW, I don't believe we need ad-hoc solution, and thus I am planning to port
> > the only missing component, nm-applet, to libappindicator soon).
> 
> NetworkManager is not easy - it uses a lot of hacks to appear as a regular
> GtkMenu.

I'll see soon, but it should not be that bad. The only strange features it uses are bold items (which just need to get around libappindicator), images on the right (but mockups say left, so no problems) and separators with labels (which are supported by the protocol but neither libappindicator and JS DBusMenu)

OK, so there are three questions here:

    1. Do we want a dbusmenu-like solution for the main status area
    2. Do we want a dbusmenu-like solution for the trayicons in the
       message tray
    3. Assuming that the answer to either 1 or 2 is "yes", do we want
       dbusmenu?


For #1, it is important to keep in mind the goals of the System Status Area redesign. (http://live.gnome.org/GnomeShell/Design/Guidelines/SystemStatus). In particular, it is not meant to contain arbitrary icons, so the "generic" case isn't as important. And it involves a redesign of almost every icon/applet; we explicitly do not want to simply translate the existing menus directly over to PopupMenu and call it good (and we also don't want to force the designs from the wiki into a lowest-common-denominator layout).

Another issue with the system status area is that it is likely that we will continue to redesign the icons and menus, and so we want a solution that makes it easy to do so without needing to coordinate changes among multiple modules.

After some discussion, we feel that the best way to do all of this is to implement the UI entirely on the shell side. For the simpler status area icons (eg, volume, a11y), this means implementing them entirely in JS. For the more complicated ones (network, power, probably bluetooth), we want to have the existing applets export information via D-Bus, and then have JS applets that read that information and construct appropriate UIs. We *don't* want the applets to export "menus" directly; the JS code will decide how to take the information about available networks, etc, and turn that into appropriate menus (making its own decisions about formatting, divisions between the main menu and submenus, etc).


For #2, it would be nice to have something dbusmenu-like for the trayicons in the message tray, so that trayicons can present a UI that is consistent with other message tray sources.


However, this brings us to #3: do we want dbusmenu itself? And we already had this discussion on the list. The KDE status notifier protocol is not the right base to build on. The fact that you *can* do it isn't really relevant; we *could* have the shell implement an ftp server, and the trayicons implement ftp clients, and use ftp to transfer data back and forth between them, with some standard conventions about what data goes in what files. But that would be dumb.


I'm sorry you wrote all this code and I'm just closing the bug without even reading it, but, well, we did already say that we weren't going to do it this way.

(In reply to comment #5)
> OK, so there are three questions here:
> 
>     1. Do we want a dbusmenu-like solution for the main status area
>     2. Do we want a dbusmenu-like solution for the trayicons in the
>        message tray
>     3. Assuming that the answer to either 1 or 2 is "yes", do we want
>        dbusmenu?
> 
> 
> For #1, it is important to keep in mind the goals of the System Status Area
> redesign. (http://live.gnome.org/GnomeShell/Design/Guidelines/SystemStatus). In
> particular, it is not meant to contain arbitrary icons, so the "generic" case
> isn't as important. And it involves a redesign of almost every icon/applet; we
> explicitly do not want to simply translate the existing menus directly over to
> PopupMenu and call it good (and we also don't want to force the designs from
> the wiki into a lowest-common-denominator layout).

That's not exact: volume and bluetooth are all more or less translations to PopupMenu of existing Gtk interfaces; power has a slightly different interface, but from bug 622451 I understood that g-p-m's maintainers (who are supposed to "know better") don't want to change a carefully designed UI; network finally is just a merging of the main and context menus, while still maintaining the main design traits.

> Another issue with the system status area is that it is likely that we will
> continue to redesign the icons and menus, and so we want a solution that makes
> it easy to do so without needing to coordinate changes among multiple modules.

What easier to change it inside the relevant module, instead of adding API in the module and using this API in the Shell?
Again, I believe indicator developers are the ones in charge of designing the best interface for their program.

> After some discussion, we feel that the best way to do all of this is to
> implement the UI entirely on the shell side. For the simpler status area icons
> (eg, volume, a11y), this means implementing them entirely in JS.

I would dissent for volume, if you don't want just show the volume bar / mute button, but want to integrate with all sound reproducing application, in which case reusing indicator-sound (aka SoundMenu) would be very useful.

> For the more
> complicated ones (network, power, probably bluetooth), we want to have the
> existing applets export information via D-Bus, and then have JS applets that
> read that information and construct appropriate UIs.

What about their existing Gtk intefaces?
- Do you plan to deprecate / unmaintain / just-let-code-rot them
- Do you want to maintain two different interfaces, for legacy GNOME and new GNOME
- Do you want to develop a new GNOME Panel applet (plus one for Xfce4/LXDE/whatever using nm-applet) interacting with this UI? 

> We *don't* want the
> applets to export "menus" directly; the JS code will decide how to take the
> information about available networks, etc, and turn that into appropriate menus
> (making its own decisions about formatting, divisions between the main menu and
> submenus, etc).

If you are talking about "available networks" and not "connection clickable items" (in a specific order and with specific icon), why not taking it directly from NetworkManager (and UPower and Bluez)?

> 
> For #2, it would be nice to have something dbusmenu-like for the trayicons in
> the message tray, so that trayicons can present a UI that is consistent with
> other message tray sources.

Except that other message tray sources (both from libnotify and GtkStatusIcon) have nothing even closely resembling a menu: how do you expect them to coexist?
> 
> However, this brings us to #3: do we want dbusmenu itself? And we already had
> this discussion on the list. The KDE status notifier protocol is not the right
> base to build on.

My point is: I haven't yet understood why. I thought that implementing it would have shown its flaws, and while I have seen something I definitely don't agree with, I don't think it is so bad.

> The fact that you *can* do it isn't really relevant; we
> *could* have the shell implement an ftp server, and the trayicons implement ftp
> clients, and use ftp to transfer data back and forth between them, with some
> standard conventions about what data goes in what files. But that would be
> dumb.

Exactly: that would be dumb. Having a protocol for trasmitting an icon, a title, a category, a status and a tooltip (which is everything you need for a status icon, plus a menu if you want) doesn't seem dumb, instead.

> 
> I'm sorry you wrote all this code and I'm just closing the bug without even
> reading it, but, well, we did already say that we weren't going to do it this
> way.

No problem about the code, but I am not satisfied by resolution :)

(In reply to comment #6)
> That's not exact: volume and bluetooth are all more or less translations to
> PopupMenu of existing Gtk interfaces; power has a slightly different interface,
> but from bug 622451 I understood that g-p-m's maintainers (who are supposed to
> "know better") don't want to change a carefully designed UI

No, he was pointing out that upower doesn't have the right *information* easily available to be able to construct a sane UI from.

> What easier to change it inside the relevant module, instead of adding API in
> the module and using this API in the Shell?

The information isn't changing, so changing the ui design in the shell won't require changing anything in the relevant modules. So changes to the shell design will only require changes to the shell.

> Again, I believe indicator developers are the ones in charge of designing the
> best interface for their program.

You're thinking of the underlying programs (nm-applet, gnome-power-manager) as being primary, and the Shell as being something that merely aggregates their outputs. That's backwards. The GNOME environment is primary, and the Shell is the interface to the GNOME environment. As part of the environment, we have information about power, networks, etc, and it is the Shell's job to display that information in a useful way. Where that information comes from is an implementation detail.

> What about their existing Gtk intefaces?

gnome-panel is not going away for 3.0. The existing applets will continue to be used for people using gnome-panel (which is one reason why we don't want to rewrite nm-applet and gnome-power-manager *entirely* in JS, since we still need the C versions as well).

So gnome-panel and gnome-shell will have separate volume applets, just like they have separate application-launching systems.

> - Do you plan to deprecate / unmaintain / just-let-code-rot them

Assuming that we move towards a future with only the Shell, with gnome-panel going away, then the existing applets would eventually go away. If we instead move towards a future with the shell and the panel both being considered "first class" parts of 3.x, then we have much larger design problems to think about, and this is just a small part of that.

> - Do you want to maintain two different interfaces, for legacy GNOME and new
> GNOME
> - Do you want to develop a new GNOME Panel applet (plus one for
> Xfce4/LXDE/whatever using nm-applet) interacting with this UI? 

In the case of nm-applet, for instance, we'd run the nm-applet process under either gnome-panel or gnome-shell. In the gnome-panel (or xfce/lxde) case, nm-applet would talk to NetworkManager, read stuff from GSettings, and construct its own UI using the trayicon protocol. In the shell case, nm-applet would do exactly the same talking to NetworkManager and reading from GSettings, but would just export the resulting information via D-Bus rather than building it into a menu, and then gnome-shell would take that information and create its own interface to it.

> If you are talking about "available networks" and not "connection clickable
> items" (in a specific order and with specific icon), why not taking it directly
> from NetworkManager (and UPower and Bluez)?

per bug 622451, upower apparently does not have all of the relevant information. In the case of nm-applet, in addition to providing the trayicon, the applet is also responsible for coordinating communication between the NetworkManager process and GConf/GSettings, and we don't want to duplicate that. I don't know the details for bluetooth, which is why I said that I wasn't sure which group it fell into.

> > For #2, it would be nice to have something dbusmenu-like for the trayicons in
> > the message tray, so that trayicons can present a UI that is consistent with
> > other message tray sources.
> 
> Except that other message tray sources (both from libnotify and GtkStatusIcon)
> have nothing even closely resembling a menu: how do you expect them to coexist?

I'm not sure what your objection here is. My point is that it might be nice to have the icons there be able to pop up menus in the shell theme rather than in the gtk theme. (Also, there are mockups of future tray-based functionality that do have menus and pop-up windows.)

> My point is: I haven't yet understood why. I thought that implementing it would
> have shown its flaws, and while I have seen something I definitely don't agree
> with, I don't think it is so bad.

Try this thread: http://lists.freedesktop.org/archives/xdg/2010-January/011228.html

The problem is that nothing in the spec is actually defined to mean anything, and so there is no real possibility of interoperability between independent implementations. Also, while KDE proposed this as a freedesktop standard, they were absolutely resistant to making any changes to it to make it more useful for other desktops. So, ok, fine. If they don't want to make it useful for GNOME, then we won't use it.

The only reason we're having the discussion at all is because Canonical then came along and tried to add a layer of sanity on top of it. If you don't look below the covers, then libappindicator is great. But we have to look under the covers, and what's there is something we don't want to be stuck with for the next 10 years.

(In reply to comment #7)
> [...]
> 
> The information isn't changing, so changing the ui design in the shell won't
> require changing anything in the relevant modules. So changes to the shell
> design will only require changes to the shell.

This depends on the abstraction level chosen for the API and it is yet to be proven.

> > Again, I believe indicator developers are the ones in charge of designing the
> > best interface for their program.
> 
> You're thinking of the underlying programs (nm-applet, gnome-power-manager) as
> being primary, and the Shell as being something that merely aggregates their
> outputs. That's backwards. The GNOME environment is primary, and the Shell is
> the interface to the GNOME environment. As part of the environment, we have
> information about power, networks, etc, and it is the Shell's job to display
> that information in a useful way. Where that information comes from is an
> implementation detail.

This approach goes in favor of pure JS implementation inside the Shell, not acquiring information from programs whose only purpose is to display the information sensibly.
If on the other hand you consider the Shell an environment in which the application offer some interfaces, and these get rendered differently based on their category, you need to go for the general UI interface.

> > What about their existing Gtk intefaces?
> 
> gnome-panel is not going away for 3.0. The existing applets will continue to be
> used for people using gnome-panel (which is one reason why we don't want to
> rewrite nm-applet and gnome-power-manager *entirely* in JS, since we still need
> the C versions as well).

But you still need GtkStatusIcon+GtkMenu and full featured DBus for UI.

> So gnome-panel and gnome-shell will have separate volume applets, just like
> they have separate application-launching systems.

And separated network, battery, bluetooth - so different people won't even think they are the same program?

> [...]
> > - Do you want to maintain two different interfaces, for legacy GNOME and new
> > GNOME
> > - Do you want to develop a new GNOME Panel applet (plus one for
> > Xfce4/LXDE/whatever using nm-applet) interacting with this UI? 
> 
> In the case of nm-applet, for instance, we'd run the nm-applet process under
> either gnome-panel or gnome-shell. In the gnome-panel (or xfce/lxde) case,
> nm-applet would talk to NetworkManager, read stuff from GSettings, and
> construct its own UI using the trayicon protocol. In the shell case, nm-applet
> would do exactly the same talking to NetworkManager and reading from GSettings,
> but would just export the resulting information via D-Bus rather than building
> it into a menu, and then gnome-shell would take that information and create its
> own interface to it.

Which boils down to 2 code paths for legacy and new protocol, completely different in approach and difficult to integrate (for example, now nm-applet builds the menu when needed, and doesn't emit any signal for changes)

> > If you are talking about "available networks" and not "connection clickable
> > items" (in a specific order and with specific icon), why not taking it directly
> > from NetworkManager (and UPower and Bluez)?
> 
> per bug 622451, upower apparently does not have all of the relevant
> information. In the case of nm-applet, in addition to providing the trayicon,
> the applet is also responsible for coordinating communication between the
> NetworkManager process and GConf/GSettings, and we don't want to duplicate
> that.

NetworkManagerUserSettings (assuming that NM 0.9 will have it) provides the necessary API for keeping the GSettings part separate, while using standard NM DBus.

> [...]
> 
> I'm not sure what your objection here is. My point is that it might be nice to
> have the icons there be able to pop up menus in the shell theme rather than in
> the gtk theme. (Also, there are mockups of future tray-based functionality that
> do have menus and pop-up windows.)

Uhm... I assume the message tray design is going to change very much from existing implementation (which pops up the notification when the summary item is clicked, and having a menu struck inside a notification looks weird)

> > My point is: I haven't yet understood why. I thought that implementing it would
> > have shown its flaws, and while I have seen something I definitely don't agree
> > with, I don't think it is so bad.
> 
> Try this thread:
> http://lists.freedesktop.org/archives/xdg/2010-January/011228.html
> 
> The problem is that nothing in the spec is actually defined to mean anything,
> and so there is no real possibility of interoperability between independent
> implementations. Also, while KDE proposed this as a freedesktop standard, they
> were absolutely resistant to making any changes to it to make it more useful
> for other desktops. So, ok, fine. If they don't want to make it useful for
> GNOME, then we won't use it.

So the problem is not the protocol, rather the spec (and some editorial changes). In fact, the protocol doesn't need any change beyond changing AttentionMovieName to AttentionAnimationName, merging signals into a PropertiesChanged, adding a Menu property and dropping parameters to Activate/SecondaryActivate, which are rather trivial and could be done in the transition from org.kde to org.freedesktop.

Secondly, all that discussion is only relevant to StatusNotifierItem, not dbusmenu. Various parts of Ayatana interface (MeMenu, MessagingMenu, SoundMenu) use dbusmenu without the kde part.

> The only reason we're having the discussion at all is because Canonical then
> came along and tried to add a layer of sanity on top of it. If you don't look
> below the covers, then libappindicator is great.

Having played with the protocol for a while, I think the biggest limitation is libappindicator itself (not allowing titles / tooltips, icons from GdkPixbuf, menus as direct dbusmenu objects, activation signals...)