Desktop Notifications Spec 0.3

[Christian Hammond]

On Wed, 29 Sep 2004 14:28:06 -0400, Bryan Clark <bclark at redhat.com> wrote:
> On Wed, 2004-09-29 at 09:39 -0700, Christian Hammond wrote:
> > Agreed. Simple messages with a little bit of HTML markup (bold,
> > italic, etc.) is probably going to be sufficient. I don't see a need
> > for complex formatting with CSS and such, but if we ever need it,
> > things can be extended.
> 
> Hey ~
> 
> Sorry I haven't been back in the discussion much but I was thinking
> about this the other day and started to realize that we're probably
> heading in the wrong direction here.
> 
> Passing XML or HTML or anything over the wire seems excessive.  I'll try
> to explain why.  Notifications are essentially a type of dialog, however
> they are at a lower level of interaction then normal dialogs and modal
> dialogs.  We have always used glade or pre-constructed dialogs in the
> application code and then replaced the %s tags with the text that needs
> to appear at the time.  This is an acceptable solution to dialogs since
> we never want applications to auto-generate dialog prompts via whatever
> messages need to be displayed.  The application programmer always knows
> ahead of time what dialogs might appear when, and roughly what they will
> say and display.

I think we're still going overboard. Why should the protocol care how
it's layed out? Shouldn't that be the particular UI impementation's
job? They are just standard dialogs, so we don't need anything besides
text, really. An image, or bold, sure, we can throw that in with
virtually no additional overhead. If we required registration of XML
files, we would once again limit our uses. A small shell script that
someone downloads would suddenly have to register an XML file in order
to display anything. Instead of just adding notifications to your
program, you'd have to make sure they were also in sync with the XML
files. Or am I misunderstanding?

I don't see a need for any kind of layout representation in the
protocol, especially since notifications can pass hints and stuff. The
UI can render specific hints how it chooses, if it chooses to even
render them differently, and if you want XML-controlled layouts, you
could perhaps have the UI look for an XML based off the hint. I don't
know.

Anyhow, I'd rather not see this any more complicated or UI-specific
than it has to be. I don't want full XML or HTML in the notifications.
I would specifically limit it to very tiny things like <b> or <i> that
can be filtered out through one tiny loop and wouldn't prevent
information loss or distort the information. Going the XML/HTML in the
body route is definitely the wrong way to do things.

Let me know if I misunderstood.