Fwd: Re: tigert's mockups and HTML

[Christian Hammond]

On Fri, Sep 24, 2004 at 05:52:52PM -0400, Franco Catrin wrote:
> 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.

That makes more sense.

> 
> > > 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

PDAs? Console? Yeah, there's still libxml and expat, I guess. It feels
weird, though, to use both D-BUS and XML, especially when we can get
those key/value pairs into a hashtable or something. Maybe I'm wrong.

> why?  because the way I see things, each desktop will make their own
> rendering
> 
> The theme is part of the desktop environment
> 
> 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.

Great, except now theme authors have to create yet another theme, even
though just using gtk or Qt would give us the themed result anyway.
These are designed to be small notifications that don't distract you.
Aside from the widget theme colors and such, what else do we really
need? Dancing hamsters, fancy borders, or background images? I don't
see the point.

> - Tigert is happy :-)

I like it when tigert is happy. I just want to make sure we don't go
down a bad route. I'm not convinced we need themes, since his stuff is
not really a theme thing. It's more about what can be put in the
notification, and how it can be laid out.

Notification popups should be small. We don't need fixed positions or
javascript or anything. We should be able to say "this text is bold"
and "insert a small image here." We don't need anything too complex.
The tags for that are easy to filter out even in a small C function,
without the need for an XML/SGML parser.

> > > - 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.

Then where's the benefit over the current method? How do we get these
complex things in the notification?

It's not themes that's really been under discussion. It's XEMBED,
XHTML, and other stuff.. What can you put in a notification.

> 
> > > - 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.

This was because everybody was yelling at me for not adding full-blown
HTML support, and I needed a way to satisfy everybody without
requiring an HTML parser or an intelligent tag stripper.

I would rather see simple markup. I don't see uses past that.

I understand we don't want to limit ourselves, but let's get a basic
thing working that still works pretty good, and decide later if we
really do need to extend the markup or add content negotiation or XML
or whatever else. For now, we have something that will work in most of
the cases. We don't even know if these hypothetical things will be
desired, or if there's a better place to put them.

Christian
 
-- 
Christian Hammond         <>  The Galago Project
chipx86 at gnupdate.org      <>  http://galago.sourceforge.net/
   Life is a sexually transmitted disease with 100% mortality.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20040924/d6af0621/attachment.pgp