Fwd: Re: tigert's mockups and HTML

[Matthew Walton]

Mike Hearn wrote:
>>  Alternative though: If this is moved so far, with almost everything 
>> done in the client, why not simply do it completely in the client? 
>> Then there's no need to have any server, case closed, issue solved.
>>
>>  Not that I'm really suggesting this, but seriously, if the server 
>> would be just showing app something XEMBED-ed, what would be really 
>> its purpose?
> 
> 
> Indeed. If presentation kept being done client side (to look fashionable 
> or whatever) then all the server would do is allocate screen real estate 
> to clients, and you might as well just extend EWMH and the window 
> managers to do that. Allowing it means that everybody will just assume 
> MSN style poptarts are being used, when currently you could have quite a 
> few types of presentation, like this :
> 
> http://arstechnica.com/reviews/01q4/macosx-10.1/images/volume-overlay.gif
> 
> The "bezel" feature is one I've seen in other Mac apps, maybe there's an 
> API for it. Anyway, you get the idea.

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.

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.

The notification system shouldn't have to worry about anything more than 
displaying the data it's given, and passing actions back if necessary. 
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?