OK, notify-osd implements this by patching the media-keys plugin in gnome-settings-daemon to use libnotify to send "notifications" like:

++        notify_notification_update (n,
++                                    " ",
++                                    "",
++                                    icon_name[s]);
++		
++	notify_notification_set_hint_int32(n, "value", value);
++	notify_notification_set_hint_string(n, "x-canonical-private-synchronous", "volume");

which seems kind of crack to me. ("Send a notification with no content and some magic hint values that cause notify-osd to do something totally different than it would have done otherwise.") (Though it *does* check that the notification server supports those hints first, which is why it automatically falls back to using the standard way once we replace notify-osd with gnome-shell though.)

We could do it more or less the same way, for simplicity/compatibility, but I think it would be better to either add a new method to org.freedesktop.Notifications for the "OSD notification" case, or else to not use org.freedesktop.Notifications here.


Problem two is how we manage to override gnome-settings-daemon in the jhbuild case, where the system gnome-settings-daemon is already running. I don't think we really want to kill and replace g-s-d with a jhbuilt version...

We could build our own g-s-d plugin module. We'd have to install it into /usr (or at least, install a symlink from /usr to the jhbuild prefix once), and we'd have to make things work so that the default media-keys plugin and our "media-keys-gnome-shell" plugins can both be running at the same time, and the shell one plays tricks to grab control of the keys when gnome-shell is running and hands them back when it's not. This would still be awkward though because g-s-d would only load a new copy of the module at login time, not every time you rebuilt gnome-shell. (Unless the module was just something that itself g_module_open()ed another module... but then we run into serious accidentally-making-gnome-settings-daemon crash territory.)

Another possibility would be to have the gnome-shell wrapper script disable the g-s-d media-keys plugin via its gconf key, and then gnome-shell can just grab the keys and handle them itself, and when it exits, the wrapper script will re-enable media-keys. (The re-enabling would happen from the wrapper script so that it still happens even if the gnome-shell process crashes.) This might be the best bet in the short term?

OK, apparently gnome-power-manager does its own OSD windows separately from g-s-d too (by cut+pasting the code...) Yay.

I'm thinking we should split the part of media-keys that listens to the keys from the part that displays the OSD. I guess there are three possibilities:

    1) We add OSD as an org.fdo.Notifications extension, and move the OSD code to notification-daemon (with notify-osd and GNOME Shell having their own alternative implementations).
    2) We add a new org.gnome.OSD interface, and have notification-daemon(/notify-osd/GNOME Shell) implement it in addition to org.fdo.Notifications
    3) We add a new org.gnome.OSD interface that runs at a particular well-known name, which g-s-d grabs, but using the D-Bus flags so that someone else can steal the name from it later, and GNOME Shell grabs that name.

So then the media-keys g-s-d plugin and gnome-power-manager would both just call the OSD D-Bus interface when they wanted to do an OSD. The default implementation of the interface (in g-s-d or notification-daemon, whichever) would look exactly like it does now (including separate composited/non-composited versions). But notify-osd and GNOME Shell would each have their own alternative implementations of it though that would get used when they were running.

The API would be something like

    <method name="DisplayIcon">
        <arg name="icon_name" direction="in" type="s"/>
    </method>
    <method name="DisplayIconAndLevel">
        <arg name="icon_name" direction="in" type="s"/>
        <arg name="level" direction="in" type="i"/>
        <arg name="max" direction="in" type="i"/>
    </method>

The level/max thing is so that you can show discrete steps as discrete UI elements. Eg, the volume indicator at the bottom of http://www.gnome.org/~mccann/shell/mockups/20090630/02-volume.png would correspond to a call to DisplayIconAndLevel("some-speaker-icon", 6, 10). The default UI would just do gtk_progress_bar_set_fraction(progress, level / (double)max).

Maybe there could also be an explicit "type"/"domain"/whatever indicator ("volume", "brightness", "eject") that the OSD implementation could use to override the icon choice if it wanted.

cc:ing Bastien since he's done a bunch of stuff with the media-keys plugin

What's the message tray?

For gnome-power-manager, the problem is known and will be solved by gnome-power-manager becoming a g-s-d plugin, we'd then do the OSD in a single part of g-s-d so as to avoid clashes between notifications of that sort.

Couldn't you implement the "message tray" as a g-s-d plugin?

The message tray is part of GNOME Shell and is also used for other things (notifications, IMs, etc; see http://www.gnome.org/~mccann/shell/mockups/20090630-demo/), and has to appear in the shell overview mode as well as the normal mode, so no, it couldn't easily be part of g-s-d.

If you're sharing the OSD code between media-keys and the new g-p-m plugin though, you'll need *some* sort of API for it though, so that could maybe work something like one of my suggestions above? (A D-Bus API that, one way or another, GNOME Shell could manage to claim.)

Also FYI, Jon has imported notification-daemon into git.gnome.org and is taking over maintenance of it I think, so having a stronger dependency on that isn't necessarily awful.

(In reply to comment #5)
> The message tray is part of GNOME Shell and is also used for other things
> (notifications, IMs, etc; see
> http://www.gnome.org/~mccann/shell/mockups/20090630-demo/), and has to appear
> in the shell overview mode as well as the normal mode, so no, it couldn't
> easily be part of g-s-d.

Right.

> If you're sharing the OSD code between media-keys and the new g-p-m plugin
> though, you'll need *some* sort of API for it though, so that could maybe work
> something like one of my suggestions above? (A D-Bus API that, one way or
> another, GNOME Shell could manage to claim.)

That would also mean that, internally, g-s-d would have to go through that same d-bus api.

> Also FYI, Jon has imported notification-daemon into git.gnome.org and is taking
> over maintenance of it I think, so having a stronger dependency on that isn't
> necessarily awful.

What does the notification-daemon have to do with this? The OSD notifications are completely separate from the code in gnome-settings-daemon.

(In reply to comment #6)
> > Also FYI, Jon has imported notification-daemon into git.gnome.org and is taking
> > over maintenance of it I think, so having a stronger dependency on that isn't
> > necessarily awful.
> 
> What does the notification-daemon have to do with this? The OSD notifications
> are completely separate from the code in gnome-settings-daemon.

One of the suggestions above was to have g-s-d only handle the key-intercepting part, and to move the gsd-media-keys-window.c part into notification-daemon, exposed via an appropriate D-Bus API.

(Which makes some sort of sense since notify-osd and gnome-shell are both treating OSDs as being related to notifications. And then the notification-daemon theme format could also be extended, to let people make their OSDs match their bubble notifications if they wanted.)

(In reply to comment #7)
> (In reply to comment #6)
> > > Also FYI, Jon has imported notification-daemon into git.gnome.org and is taking
> > > over maintenance of it I think, so having a stronger dependency on that isn't
> > > necessarily awful.
> > 
> > What does the notification-daemon have to do with this? The OSD notifications
> > are completely separate from the code in gnome-settings-daemon.
> 
> One of the suggestions above was to have g-s-d only handle the key-intercepting
> part, and to move the gsd-media-keys-window.c part into notification-daemon,
> exposed via an appropriate D-Bus API.

OK, that makes complete sense, though some more complicated uses of the OSD widget are being done for the g-s-d xrandr plugin, to handle Fn+F7.

> (Which makes some sort of sense since notify-osd and gnome-shell are both
> treating OSDs as being related to notifications. And then the
> notification-daemon theme format could also be extended, to let people make
> their OSDs match their bubble notifications if they wanted.)

I guess this means that gnome-shell would be implementing the spec, as well as notification-daemon for those spec changes.

(In reply to comment #0)
> Not sure if this is a Shell bug but certainly involves the Shell.
> 
> The GNOME volume, brightness, eject, etc system feedback should use message
> tray instead of its own overlays.
> 
> These are produced by gnome-settings-daemon.

To follow up on our discussion on IRC yesterday, do we still want this in the messagetray?

I'm now leaning towards no.  A few reasons for that.  In all cases these provide visual confirmation or feedback for things that either don't have an onscreen controls or a way to display feedback for the action.  In order answer questions like did that do anything and is it going in the right direction etc.

Typically these are from keyboard hotkeys or hardware buttons.  Simply because they don't require on screen controls to work.

They include things like:
 * Monitor output configuration
 * Monitor brightness level
 * System volume level
 * Media keys (play, eject, etc)
 * Workspace change
 * (kinda) Application switch

I think it makes the most sense to display these close to where the action is taking place.  This is particularly important when using the Application switcher (alt-tab) because it allows mouse interactions too.  There is also some value in being larger and more up front since these are user initiated.

These same things don't really apply to messages.  In fact the opposite is usually true.  I want them to not be in my face and be in a stable location when I'm ready to see them.  Current notification daemon's pop notifications up where the mouse is and that turns out to be really annoying.

The "OSD" type popups should be popping up on the same screen that has the keyboard focus, just below the center of the screen currently.

Also note that we would only make the media keys pop something up if there wasn't any applications handling them (so that the user knows that the keys have been pressed, otherwise, the application skipping/pausing would usually be feedback enough).

So one issue that we may want to think about longer term is - besides ensuring that they all look consistent - do we want to make any of this available on the locked screen.  I think the volume and brightness would really be nice to have.  One possible way to do that is to have the locked screen handle the keys (since it will get them anyway) and forward them to gsd.  But how would we present feedback for them.

I wonder if the shell should provide API to display the OSD itself?  gsd could ask the shell to present something on its behalf.  Does this make sense?

The one thing this would allow is drawing OSD when the shell is in overview mode (although I don't even know if gsd can receive the key presses in that mode).

Passing the keypresses from gnome-screensaver to gsd sounds easy enough, though kind of orthogonal to this discussion.

As for the consistency in display, you'll always have that problem, because people could just as well install 3rd-party plugins/applications, and break that. So, do we want to allow other applications and add-ons to popup OSD windows? Then we can discuss how would should make it available to them. But I don't see anything that I would want displaying OSD popups and that isn't "core desktop" (so already integrated, or that should be integrated).

Should we rename this bug into something like "Make volume, brightness, and other system feedback available on the locked screen and in the overview" ?

(In reply to comment #14)
> Should we rename this bug into something like "Make volume, brightness, and
> other system feedback available on the locked screen and in the overview" ?

Sounds good to me.

We should allow gnome-settings-daemon (and only gnome-settings-daemon) to tell gnome-shell to show a particular OSD (be it volume, or other brightness related events), as it would be able to display the OSD even in overview mode.

Once this is implemented, gnome-settings-daemon should be modified to use this facility instead of its own OSD code.

In bug 613543 I ended up reimplementing the whole media-keys plugin in gnome-shell, including the OSD windows.
If that bug is approved for merging, this one is automatically obsolete.