GNOME Bugzilla – Bug 624361
System status area
Last modified: 2010-11-09 15:21:25 UTC
We need to implement the system status area, per http://live.gnome.org/GnomeShell/Design/Guidelines/SystemStatus This means: - Evict trayicons to the message tray. Bug 608869 has a needs-work patch that splits the tray in two; we may want to keep it that way during the transition, but eventually *all* of the trayicons should be in the message tray. There should not actually be a single "tray" in either the panel or the message tray though; the icons being presented via the trayicon protocol should be able to be intermingled with non-trayicon status area icons and non- trayicon message tray sources. - Implement the infrastructure for in-process status icons (bug 621705) and the necessary improvements to PopupMenu (bug 623625, bug 623498, bug 621880, etc) - For status icons where we need to get data from other processes (nm-applet, etc), get D-Bus interfaces added so we can get that data. - Implement the status area items themselves. In several cases, the designs on live.gnome.org do not seem to be complete, however.
(In reply to comment #0) > We need to implement the system status area, per > http://live.gnome.org/GnomeShell/Design/Guidelines/SystemStatus > > This means: > > - Evict trayicons to the message tray. Bug 608869 has a needs-work > patch that splits the tray in two; we may want to keep it that > way during the transition, but eventually *all* of the trayicons > should be in the message tray. There should not actually be a > single "tray" in either the panel or the message tray though; the > icons being presented via the trayicon protocol should be able to > be intermingled with non-trayicon status area icons and non- > trayicon message tray sources. This definitely blocks on bug 617224 - you don't want to have summary items which show the title on hover and a notification on click, mixed with icons that show an out-of-place tooltip on hover and sometimes a menu on click, mixed with icons showing the title on hover and a menu on click (through dbusmenu). > - For status icons where we need to get data from other processes > (nm-applet, etc), get D-Bus interfaces added so we can get that data. For some indicators, this is straightforward (bluetooth has bluetooth-applet, power has gnome-power-manager, network has nm-applet) - what about the rest? For keyboard / a11y, should we interface with GConf / GSettings (and let gnome-settings-daemon apply the settings to X), or should we communicate with gnome-settings-daemon using an appropriate DBus API? Similarly for volume: should we go PulseAudio, or through gnome-settings-daemon? What about XRandR? Or the backlight part of gnome-power-manager? How do you plan to merge XKB with XIM/IBus? Do you want to drop a new plugin for gnome-settings-daemon? What about additional hardware icons an user may have (phone, printer...)? Are they mercilessly sent to message tray, using the horrible old protocol? As a side question: should we hook inside gnome-power-manager / gnome-settings-daemon like notify-osd, and display volume/backlight/keyboard light changes inside the shell? (maybe through decent and reusable additions to Galago Notifications, instead of providing patches) > - Implement the status area items themselves. In several cases, the > designs on live.gnome.org do not seem to be complete, however. Is it appropriate to add in that pages proposed DBus UI/client management API? Just to see if I understood the right abstraction layer.
(In reply to comment #1) > For keyboard / a11y, should we interface with GConf / GSettings (and let > gnome-settings-daemon apply the settings to X), or should we communicate with > gnome-settings-daemon using an appropriate DBus API? A11y should just use GSettings/GConf. The keyboard/XKB/XIM/IBus situation is not actually figured out yet, so we don't know how that's going to work. (Jon sent more mail to gnomecc-list about this today.) > Similarly for volume: should we go PulseAudio, or through > gnome-settings-daemon? However the current applet does it. > What about XRandR? That's not part of the current system status area design. > What about additional hardware icons an user may have (phone, printer...)? Are > they mercilessly sent to message tray, using the horrible old protocol? Yup. > As a side question: should we hook inside gnome-power-manager / > gnome-settings-daemon like notify-osd, and display volume/backlight/keyboard > light changes inside the shell? (maybe through decent and reusable additions to > Galago Notifications, instead of providing patches) There was a bug about this, and a mockup for displaying OSDs in the message tray instead of as translucent overlays. But then Jon decided he preferred the current system. > > - Implement the status area items themselves. In several cases, the > > designs on live.gnome.org do not seem to be complete, however. > > Is it appropriate to add in that pages proposed DBus UI/client management API? > Just to see if I understood the right abstraction layer. I'm not sure what you mean?
(In reply to comment #2) > (In reply to comment #1) > > For keyboard / a11y, should we interface with GConf / GSettings (and let > > gnome-settings-daemon apply the settings to X), or should we communicate with > > gnome-settings-daemon using an appropriate DBus API? > > A11y should just use GSettings/GConf. The keyboard/XKB/XIM/IBus situation is > not actually figured out yet, so we don't know how that's going to work. (Jon > sent more mail to gnomecc-list about this today.) > > > Similarly for volume: should we go PulseAudio, or through > > gnome-settings-daemon? > > However the current applet does it. Ok for all (and going to implement something, if I manage) > > > What about XRandR? > > That's not part of the current system status area design. May I ask you why? > > What about additional hardware icons an user may have (phone, printer...)? Are > > they mercilessly sent to message tray, using the horrible old protocol? > > Yup. Doesn't that conflict with the design? It is the System Status area, not the NetworkPowerBluetooth Area, just show everything relevant to system status. In fact, the design calls for "optional or transient indicators", and says "you should *probably* not be using the System Status Area. *Often* the Message Tray is a better fit". We cannot just predict all possible hardware where GNOME Shell will be used, and all different configurations. > > As a side question: should we hook inside gnome-power-manager / > > gnome-settings-daemon like notify-osd, and display volume/backlight/keyboard > > light changes inside the shell? (maybe through decent and reusable additions to > > Galago Notifications, instead of providing patches) > > There was a bug about this, and a mockup for displaying OSDs in the message > tray instead of as translucent overlays. But then Jon decided he preferred the > current system. Ok, but consider that the current approach is sub-optimal, relying on modules to manually copy code from gnome-settings-daemon, code which is oriented towards volume and not extensible. Having a way for applications to ask for OSD, and the environment to provide them in the most appropriate way (notify-osd, message tray, or simply translucent windows, but drawn in Clutter) would be an improvement, IMHO. > > > - Implement the status area items themselves. In several cases, the > > > designs on live.gnome.org do not seem to be complete, however. > > > > Is it appropriate to add in that pages proposed DBus UI/client management API? > > Just to see if I understood the right abstraction layer. > > I'm not sure what you mean? Editing the wiki (GnomeShell/Guidelines/SystemStatus/*), adding the DBus API to the end of the page, using that for discussion / flamewar
(In reply to comment #3) > > > What about XRandR? > > > > That's not part of the current system status area design. > > May I ask you why? I don't know. Either Jon didn't want it there, or he just forgot about it. At any rate, I'm pretty sure it's pretty simple; just some XRandR calls, or perhaps some libgnomedesktop calls. > Doesn't that conflict with the design? It is the System Status area, not the > NetworkPowerBluetooth Area, just show everything relevant to system status. Presumably there will be updates to the design, and it will probably be extensible via the extension mechanism. > [OSD stuff] I'm not saying that the current system is great, it's just that since we're not planning to make any UI changes to it for 3.0, we don't *need* to make any code changes either, and there's plenty of other stuff we do need to get done. OSD is Somebody Else's Problem for now. See bug 607029 for the discussion from when we were planning to change it though. > Editing the wiki (GnomeShell/Guidelines/SystemStatus/*), adding the DBus API to > the end of the page, using that for discussion / flamewar yes, go ahead
(In reply to comment #4) > (In reply to comment #3) > > > > What about XRandR? > > > > > > That's not part of the current system status area design. > > > > May I ask you why? > > I don't know. Either Jon didn't want it there, or he just forgot about it. > > At any rate, I'm pretty sure it's pretty simple; just some XRandR calls, or > perhaps some libgnomedesktop calls. Wouldn't that conflict with g-s-d applying its own settings (I have no idea where they come from)? (And unfortunately it's not libgnomedesktop, it's libgnomeui, which MustDie) > > Doesn't that conflict with the design? It is the System Status area, not the > > NetworkPowerBluetooth Area, just show everything relevant to system status. > > Presumably there will be updates to the design, and it will probably be > extensible via the extension mechanism. Better than nothing, I suppose. > > [OSD stuff] > > I'm not saying that the current system is great, it's just that since we're not > planning to make any UI changes to it for 3.0, we don't *need* to make any code > changes either, and there's plenty of other stuff we do need to get done. OSD > is Somebody Else's Problem for now. See bug 607029 for the discussion from when > we were planning to change it though. Ok, it was just a side issue anyway. > > > Editing the wiki (GnomeShell/Guidelines/SystemStatus/*), adding the DBus API to > > the end of the page, using that for discussion / flamewar > > yes, go ahead Power is there, network will follow soon.
All indicators for which DBus APIs are needed (bluetooth, power, network) have their proposal in the wiki. I am awaiting a review to start implementing the shell part.
(In reply to comment #6) > All indicators for which DBus APIs are needed (bluetooth, power, network) have > their proposal in the wiki. I am awaiting a review to start implementing the > shell part. Bastien seems to think that the bluetooth-applet is mostly presentation, so I guess our applet should talk directly to BlueZ as well (or whatever it is that the bluetooth applet talks to). Other than that, the APIs look good enough; they don't need to be perfect right away. You may discover as you start implementing that it would be easier/better to change things around a little. And if we want to rename things later on, that's no big deal.
I'm gonna close this; the generic stuff is all done now, and I don't think we need a tracking bug for the rest.