Fwd: Re: tigert's mockups and HTML

[Franco Catrin]

El vie, 24-09-2004 a las 18:09, Christian Hammond escribió:
> 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??:

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

May be I have problems with english

I've never wanted to say something about changing the transport protocol
(D-BUS in this case).  Just change the content

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

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.

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

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.

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.

> 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

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

we don't need, but is not hard to add them with a right choice of data
content

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

> Notification popups should be small. We don't need fixed positions or
> javascript or anything.

No, please God no.


>  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

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

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

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

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)

Putting HTML into the notification is like putting absolute values into
a GTK dialog.

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

I agree

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.

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

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