Fwd: Re: tigert's mockups and HTML

[Franco Catrin]

El vie, 24-09-2004 a las 17:21, Christian Hammond escribió:
> On Fri, Sep 24, 2004 at 05:08:05PM -0400, Franco Catrin wrote:

> > A different approach is to send notifications as a formal XML, it may
> > include all the current parameters, simplifying the protocol. (that's
> > another topic)
> 
> Really, that's no different than just using D-BUS, except if we use
> D-BUS, we don't have to invent our own transport mechanism or
> anything. The XML doesn't really gain us anything, since we can
> structure our parameters and such in D-BUS messages anyway.

I wanted to say that instead of using several items packaged as a D-BUS
message, it would be more extensible to put just one string with the
embedded parameters.  Not all of them if you want.


> > This XML will be rendered by the notification applet as good as it can.
> > 
> > A simple notification applet will render this XML as a simple markup
> > language, like the one used right now.
> > 
> > A more complex notification applet will render this as XHTML as tigert
> > wish.
> 
> This still requires that every implementation have a full-blown parser
> to weed out things and support others.

It would not.

GNOME notifier should use libxml, by sure it is already loaded by
another desktop service

KDE notifier should use their own xml library (they surely have one).

I don't see the need for notifier implementation to included any type of
embedded xml parser


> > For this rendering to take place, the applet could use simple parsing,
> > or use a XSL file to make the conversion.
> > 
> > Then, the HIG and/or the notification spec should say what tags should
> > be included in the notification.  Theme authors should provide the XSL
> > for their theme, solving the problem of consistency between the
> > notification presentation and the desktop theme.
> 
> If we theme notifications, we start to break the cross-desktop
> functionality we want. 

why?  because the way I see things, each desktop will make their own
rendering

> A particular desktop environment would no
> longer be able to say exactly how they want the notification to look,
> unless they overrode the theme,

The theme is part of the desktop environment

>  but that's assuming we want the
> notification to look like something that can be produced using XHTML +
> CSS.

Not necessarily.  As I wrote in the original email, a "poor"
implementation will just use the current way of presenting the
notification content.


> It's also more heavy-weight than we need. Remember, these are passive
> popup notifications. There are other things that can be used for more
> complex information.

I'm only trying to get tigert's ideas to the current spec, without
adding complexity in the client and/or spec


> > Simple example:
> > 
> > Application client sends:
> > 
> > <?xml blah bla.. ?>
> > <notification>
> > 	<title>Low Battery</title>
> > 	<text>Your battery is too low, go and plug your machine</text>
> > 	<icon>battery</icon>
> > 	<sound>alert</sound>
> > </notification>
> > 
> > A simple notification applet (or configuration) will render:
> > 
> > <span size="large" weight="bold">Low Battery</span>Your battery is too
> > low, go and plug your machine
> 
> Grabbing the D-BUS message and pulling the correct parameters out and
> building the string would be just as easy. Maybe even faster?

Yes, it's easier, but it limits the handling of the notification
content.

With XML/XSL, a notification system like tigert wish is doable, without
adding complexity as a requirement, but as an option.


> > Benefits:
> > 
> > - Clients are simple
> 
> We have this already. More so than what would be needed if we had to
> invent a new transport layer and require XML in a certain format.

Ok, I should say

Client are still simple, and.....


> > - Notifications are themeables
> 
> I'm not convinced this is a good thing. In fact, it really isn't,
> largely for the reasons I stated above.

The theme for the notification is handled by the theme author and not by
the notification applet implementation neither the client author with
HTML embedded into the code (cof! cof!)

For example, if there is a notification applet capable of generating
XHTML through XSL from the notification XML, then Ximian people will
come with their XSL for Industrial, while RedHat will add their XSL for
BlueCurve.

- Notification clients are still the same

- The notification applet is just one piece of code, written just once. 
Complexity is on libxml and the HTML renderer, both mantained outside

- Every desktop has it's own way of showing the notification

- Tigert is happy :-)

> > - Low end machines still work fine, while high end machines render
> > powerful notifications, like the one drawn by tigert
> 
> People will start making notifications that only look right in those
> high-end machines. This is not good. It defeats the entire purpose of
> what I'm trying to do here.

No no.  People will just use the XML Notification Document Type, they
don't know how the notification will look, and they don't need to
anyway.


> > - Notifications are extensibles, this should make implementations more
> > easy to update to newer needs
> 
> They already are, and we can always add to the spec later.

Ok

> What we're ultimately deciding is how the content should be. I will be
> announcing an updated spec this weekend. The main highlights will be
> that the body is to have simple markup only, with a few select tags,
> and that there will be an *optional* html-body hint, for those who
> wish to do bigger things.

bad idea.  What you are doing there is what you are complaining above:

"People will start making notifications that only look right in those
high-end machines"

And embedding HTML in the notification will add a lot of complexity,
they will look all different or you should enforce HIG into application
code, it won't match on other desktops.  I really don't see why HTML
embedded in the notification should be better than HTML produced in the
notification applet implementation.

>  I will also explain more about actions,
> because it seems that people forgot about them entirely and want to
> just embed links everywhere in their notifications, which is a no-no.

I agree with that.

> There will be other things too. I just can't think of them off-hand.

Ok
-- 
Franco Catrin L. TUXPAN
http://www.tuxpan.com/fcatrin