Re: notification enhancements

["Christian Hammond" <chipx86 chipx86 com>]

Hi Havoc.

On 4/24/07, Havoc Pennington <hp redhat com> wrote:

Hi,

Trying to figure out a couple of problems at once.

First a longstanding issue, which is the Mugshot notification popups
colliding with the ones from notification-daemon. As will be obvious to
anyone who's looked at both, there is no way imaginable to use libnotify
to get the Mugshot UI, but the two popups should coordinate so only one
is visible at a time, and also they should probably share the logic for
detecting a fullscreen app or detecting user idleness

You say there's no way imaginable to use libnotify, but I'm curious why? I understand the argument of having to support older distros (all too well, as we have that problem at VMware). However, is there a reason you can't use libnotify if it exists and use your own thing if it doesn't?
 

Second is a simpler thing, in wanting to do Google calendar or mail
notifications, Bryan made me a design that's roughly similar to
libnotify but has a few little details that aren't implementable with
the current protocol version.

Why can't this use libnotify? Same reason as Mugshot? Or is this a part of Mugshot?
 

Third, Big Board and Mugshot are supposed to work on the last year's
worth of Linux distribution releases or so, which makes it hard to
modify notification-daemon, at least in the short term.

Sure, but as mentioned above, you could use libnotify if available and fall back to your own thing if not. You're unlikely to collide with other notifications on a system that libnotify doesn't exist on, and nearly all newer distros (that ship GNOME at least) have libnotify/notification-daemon set up and working by default.
 

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.

I wouldn't be opposed to this, but I'd like to explore other options first.

 

A simple extension of that API would also provide calls or signals to
detect idleness and fullscreen app / screensaver. Or perhaps it's
simpler than that - maybe when an app is fullscreen or the user is idle,
the daemon claims "I am showing something" and thus blocks all other
notifications.

Not sure I follow this one.. If an app is fullscreen or hte user is idle, notification-daemon should claim it's showing a notification? Why?
 

In the short term, here are some hacks I can come up with:
  - use Xlib hacks to try and determine when a notification
    window is on the screen

Notifications in notification-daemon are backed by theme engines, and as such you can't really check for a specific type of window.
 

  - take over the notification service from notification-daemon and
    provide the same D-Bus API

This seems like a bad idea. We can do better. notification-daemon is pretty well established and people are used to seeing notifications, so suddenly pulling them out from under the user is probably undesirable.

My order of preference would be:

1) Make Mugshot use libnotify in some form if available, falling back to its own thing if not.
2) Extend the protocol to say "This area on the screen is reserved," and have the notifications move (if already displayed) to an area outside that area. This would allow your notifications to say "Give me this area for my notifications," display them, and then say "I don't need the area anymore."
3) Extend the protocol so notification-daemon can emit that notifications have been added or that all have been removed. Allow "pausing" of notifications briefly.

Christian

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