Fwd: Re: tigert's mockups and HTML

[Mike Hearn]

> No API that I'm aware of, but it's easy enough to make a window that 
> looks like that.
> 
> I just thought I should mention a project called Growl, which is a 
> notification server for OS X. These discussions are very interesting to 
> us, as we have some of the same problems in defining exactly what 
> applications should pass to us and how we should render it. Having 
> multiple view plugins complicates things somewhat, but does have the 
> useful side effect of forcing a more semantic data presentation format 
> upon us.

Yes, I've heard of Growl. It seems we have a lot in common. Obviously, 
MacOS doesn't have DBUS but maybe co-operation would be possible on the 
semantics (for ease of porting) if not the technology.

Mac isn't a free desktop, but still ...

> As I see it, anyway, you *could* use HTML, but it's going to be 
> completely irrelevant for some cases, and I don't see any real reason 
> why an XML language based on a useful subset of HTML (or something like 
> Pango markup) wouldn't be sufficient. Actions are of course a problem - 
> Growl has one action per notification, but we're looking at adding 
> multiple ones, and it seems that the best way to do it is to pass 
> something back to the notifying app so that it has to worry about what 
> to do to trigger the action, and we don't have to bother.

Currently the way it works is that you provide a mapping of notification 
ids to names, like so:

0 -> "default"
1 -> "Read Mail"
2 -> "Chat with Matthew"

and so on. Zero is special, it's the default action, which in the 
current ref impl is invoked by clicking anywhere in the notification window.

The action IDs don't have to be sequential and are UINTS, so I guess on 
32-bit systems at least you could stuff a function pointer into them :) 
   <duck>

> The notification system shouldn't have to worry about anything more than 
> displaying the data it's given, and passing actions back if necessary. 

This is my feeling as well ... I'm a bit concerned the spec could easily 
end up over-engineered. Somebody actually has to *write* all this code!

> Otherwise you end up tying far too much into the notification system 
> itself, and in the fdo case, if a GNOME notification server handles a 
> new mail notification from KMail, does it really need to be able to 
> figure out that KMail is the thing that the user probably wants to use 
> to read their email, or should it just send 'read' back to KMail and let 
> it worry about it?

Right.