Re: notification enhancements

["Christian Hammond" <chipx86 chipx86 com>]

Nate, In order for that to be useful, we would need to get every window manager up to spec. That's not likely to happen any time soon. It's an idea that's been brought up in the past, but it's not unreasonable to have a notification service handle this.

So Havoc, you're completely right. libnotify and the notification spec doesn't provide what you need, and there are a couple other apps out there (Thunderbird for instance, and I'll be using this as my example from here out) that also wouldn't fit in, and we need to take these into account. The problem is that Mugshot and Thunderbird have different needs as far as how things are going to be presented (not just layout, but visual styles). While taking over the Notification service would work for Mugshot, it wouldn't work a second program that has yet another way of presenting notifications.

I've been thinking about what to do about this situation and I've talked it over with a friend who works on the Growl project (notification service for MacOS X). I think this proposal will solve the problems you're experiencing:

Two new commands would be added to the notification spec. Something along the lines of BeginCustomNotify/EndCustomNotify (we can work out the exact names later).

When an application wants to display a custom notification (such as Mugshot or Thunderbird), they would call BeginCustomNotify, passing in the width and height of the notification they're going to display. This happens after the notification has been constructed but before it's shown.

BeginCustomNotify would return an x, y location and an ID. Internally, it's reserved a spot at x,y of width, height, and won't display any notifications there. Once the application gets this result back, it is free to display the notification there, handling it however it chooses. It's just a reserved area in the notification stack now, nothing more. It manages its own timeout, layout, and interaction rules.

When the application discards the notification, it sends an EndCustomNotify with the ID it received. This informs the notification service that the area is no longer reserved, and allows it to shuffle the notifications or place a new notification in that area.

There are a lot of advantages to this approach:

1) It's simple. Two new commands, both taking minimal input and only reserving an area in the stack, giving the application full control of what happens in that area.

2) Prefs don't have to be duplicated. Notification-daemon has preferences for specifying which corner of the screen is the base for the stack, and Mugshot/Thunderbird/whatever wouldn't have to know about this. It only has to know that it's supposed to display the notification at a specific location.

3) Multi-head logic doesn't have to be duplicated. There's an experimental patch for basically implementing a Xinerama-aware _NET_WORK_AREA so that notifications will always appear at the right place on whatever head the mouse cursor is on, taking into account panels and different screen sizes. Since X and the window manager don't do this for us, there's a lot of work to do to get these areas. The application using this new API would never have to know or care about this.

4) Multiple applications can make use of this. Replacing the notification service only benefits the application(s) compatible with that new implementation. There's also the problem that any new custom features in that notification service aren't part of the spec and therefore can't be relied upon on distros that ship notification-daemon or some third party daemon. With this method, everything can play nicely together.

5) Other notification implementations can be shoe-horned into this. I highly doubt Thunderbird would actually support this natively any time soon, especially due to the lack of dbus support (has this changed?) but I see no reason why an extension couldn't be developed to grab a reserved area and move the notification to that spot.

The only other thing that we need to take into account is that when the stack changes, we will need to inform the app that their notification needs to move on the stack. That shouldn't be difficult either, just a signal or something.


Would this solve the problem for you? This is the route I would strongly prefer to go in, as it adds to a now well-established component of the desktop and greatly enhances what applications can do with it. Gives it the capability of a "popup-manager," as Matthias put it.

Christian

On 4/26/07, Nate Nielsen <nielsen-list memberwebs com> wrote:

Matthias Clasen wrote:
> On 4/24/07, Havoc Pennington <hp redhat com> wrote:
>
>> Given those issues, there are obviously long-term and short-term approaches.
>>
>> In the long term, Owen suggested that notification-daemon export more of
>> a "coordination" API, that would allow multiple apps that want to pop
>> something up to say "I am showing something now" and block the other
>> cooperating apps during that time.
>>
>
> Time to introduce a "popup manager", rather than continuing down this
> road towards
> cooperative management of override-redirect windows ?

A suggestion:

Shouldn't the window manager arbitrate stuff like window layout and
positioning? If we're going to invest in some sort of coordination, it
might as well be in the window manager rather than yet another API.

Cheers,
Nate Nielsen

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

-- 
Christian Hammond - chipx86 chipx86 com
VMware, Inc.