Fwd: Re: tigert's mockups and HTML
matthew at alledora.co.uk
Fri Sep 24 12:31:20 EEST 2004
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 :
> 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
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?
More information about the xdg