Re: notification enhancements

[Havoc Pennington <hp redhat com>]

Hi,

Christian Hammond wrote:
> 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).

I would put this somewhat differently; I think the needs are not just 
visual style but content (what controls there are and what information 
is shown).

Also in the Mugshot case there's a link in the user's mental model 
between the "browse" mode (see all the past notifications in a 
scrollable window) and the individual notifications. So it's important 
that the two "match."

An example of how this might matter, we currently display up to three 
Mugshot notifications at once; we'd probably want to treat those as one 
notification in the notification-daemon stack so they stay together.

(It would be tough to do otherwise anyhow since they are all in one window)

> 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.

This is probably implied but you'd also need the X screen, and be able 
to update the x,y over time, I would think.

The app would also need to be able to update its width/height, e.g. in 
Mugshot you can "expand the block"

> 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.

It is more complex than what I was thinking, though, which was perhaps a 
Begin/End lacking the coordinate stuff; the custom notify would simply 
replace the stack for its duration, then the stack comes back.

> 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.

Right now Mugshot shows the notification next to the Mugshot icon; it 
seems like we need to keep doing that. Especially since if you click the 
icon, it opens the "browse mode" (all past notifications) in a window 
that is also positioned next to the icon. You can also "convert" a 
notification into the browser window. If the notification weren't shown 
next to the Mugshot icon, then the interaction breaks down a bit.

> 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.

I think it would probably make the above-mentioned problem worse to show 
the Mugshot notification on another monitor... I would expect that the 
notification is always on the monitor with the Mugshot icon...

> 4) Multiple applications can make use of this. Replacing the 
> notification service only benefits the application(s) compatible with 
> that new implementation.

If it wasn't clear, I was only suggesting replacing notification-daemon 
as a hack for old notification-daemon versions. (I don't think I'll 
bother to be honest since it's not a big enough problem to maintain a 
weird hack.)

My suggestion going forward was like Begin/End custom but without the 
coordinates; more just a cooperative system where one app at a time can 
have the "notification baton" and if nobody has it, then the 
notification daemon has it. Apps must have the baton in order to display 
notifications. If an app has it, then notification-daemon holds its 
notifications until it gets the baton back.

> Would this solve the problem for you?

I'm not sure the positioning stuff always makes sense (though it could 
be useful in some cases, so maybe it should be optional). Other than 
that it is the basic idea I had in mind.

> Gives it 
> the capability of a "popup-manager," as Matthias put it.

Though, I'm not quite sure what Matthias meant by that, so Matthias if 
you think we are on crack here please explain further ;-)

Havoc