Fwd: Re: tigert's mockups and HTML

[Christian Hammond]

On Fri, Sep 24, 2004 at 06:50:56PM -0400, Franco Catrin wrote:
> > 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.
> 
> Yes we can.  The problem is that any kind of transformation will
> requiere code for it, embedded into the notification applet
> 
> With XML you can still have good results but without enforcing them,
> just making them possible.

With XML, we can have added overhead with no realistic benefit.

We do not need to add theme support to this spec or to any spec for
notifications. We get that for free on implementations that use it,
and other ones shouldn't be told how to display this.

I will not be putting themes into the spec.

> > 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.
> 
> No, they don't need to.
> 
> Let's say we are implementing a simple notification applet for a small
> desktop environment in GTK.  The only thing to do is to extract the data
> from the XML, and then render that in GTK
> 
> Now let's say that we are implementing the notification applet for GNOME
> capable of rendering HTML.  The code will just extract some data from
> the XML and then convert it with the XSL for the current theme.  If
> there is no such XSL, then the notification applet will may use its own
> default XSL or render the thing with GTK.

That's way more complicated than a simple notification should ever be.
This is just a bad path.

> If and only if the theme designer want's to improve the notification
> rendering, they will provide a custimized XSL.  What I've seen from
> tigert mockups, I'm sure there will be people interested on it.

We don't need anything this complicated for his mockups.

> > 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.
> 
> Compare this:
> http://tigert.gimp.org/log/archives/2004/09/24/evolving/
> 
> with this:
> http://gnotify.sourceforge.net/screen3.png
> 
> Both types can be possible with the same client.  At no cost

Both can be done without all this overhead and messiness.

> > 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,
> 
> we don't need, but is not hard to add them with a right choice of data
> content

Allow me to rephrase that. We shouldn't have 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.
> 
> The lay out will be decided by the applet implementation, or in the XSL
> case by the XSL author who may be better making a good visual design
> rather that coding.

The layout should be decided by the daemon and not through markup, and
certainly not through something with as much overhead as XSLT.

> >  We should be able to say "this text is bold"
> > and "insert a small image here."
> 
> moving the visual details to the client restrict what people can do
> outside the client.  Most programmers are not good user interface
> designers

It's not about presentation or visual details. It's about content.
Wrapping something in <b>...</b> shows that it's important, it
requires some emphasis, but the display is decided by the UI. Yes, <b>
is technically "bold," but what about <strong> and such? That's
content, not presentation. I'm not talking about handing <table>
commands to the user.

> >  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.
> 
> If they are easy, then XML are easy too. An XML for a notification could
> not be harder than that

The logic here is very wrong. Writing a filter is cake. Writing an XML
parser is another beast.

> > > 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? 
> 
> The benefit is that someone with talent (like tigert) can decide how
> they will look good.  And it can cover other desktops like KDE or XFCE
> easily

Exactly what should not be done. Desktops should decide, not us. This
is precisely what I want to avoid.

Guys, we're popping up simple notifications that won't be on the
screen long. We don't want this much pain and hassle for it. More
advanced stuff should be done in other ways.

We're going way overboard. We can make notifications look sexy and
stuff without shoving all this crap into a notification and requiring
transformations and such.

> > 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.
> 
> A notification should include nothing more than content, and may be some
> visual hint like an icon.  Almost just like the current spec.
> 
> The difference is that the notification applet MAY delegate the
> rendering to another piece of code (XSL processor + XHTML renderer)

they can do this already. We're talking meta-data. We don't need XML.
XSL is overkill.

> Please don't put HTML on the notification.  Let the content be provided
> by the client and the notification be rendered by the notification
> applet (or other implementation)

I don't want HTML in there either. Simple content-related markup tags,
sure.

> > I would rather see simple markup. I don't see uses past that.
> 
> XML is a simple markup.  In this case is specially simpler than a markup
> with visualization tags

I don't want XML in there.  It's just added complication to something
that gives us no real benefit. You can make up benefits, but those
supposed benefits can be achieved already.

> Another road that is to take an intermediate route being implementation
> specific.  For example that the GNOME notification applet create an XML
> on the fly using the current spec.  Then this XML is converted in XHTML
> using the XSL provided by a theme author, and this one is rendered by an
> XHTML renderer.

How does that gain us anything?

I get the impression you want your notifications to look like
miniature web pages and to play with XSLT. This is no reason to make
the spec wrong.

> Benefits
> 
> - It can be implemented without touching the spec
> - It can be implemented in the future, without stopping the use of
> current implementations
> 
> Drawbacks
> - If markup for visualization is included in the data sent by the client
> application, there will be a conflict with the XSL rendering

 - It's pointless and serves no gain.

Christian
 
-- 
Christian Hammond         <>  The Galago Project
chipx86 at gnupdate.org      <>  http://galago.sourceforge.net/
   dang, it's windy outside. i think i'm going to be sucked
   into a tornado. here we go!!!! weeeeeee
-------------- 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/31c9824a/attachment.pgp