Desktop Notifications Spec 0.3

[Olivier Goffart]

Le Jeudi 16 Septembre 2004 11:53, Mike Hearn a écrit :
> Christian Hammond wrote:
> > Hey everyone.
> >
> > Mike Hearn and I are announcing version 0.3 of the desktop
> > notifications spec today. 

I've already replied to that mail before.  But i don't know why, it is not yet 
arrived on the list.   It maybe will arrive soon.

> The current reference implementation (on my laptop) has the following
> attributes:

I have myself worked on a basic KDE deamon.  It simply uses KPassivePopup, 
And it is actualy (temporary) using DCop insteads of DBus (that's faster and 
easier to code)

> - It supports most of the spec, including:
>
>    - All the basics needed to actually display a notification
>    - Static images
>    - Actions, represented as hyperlinks a la the mockup in the GTK+
>      backend
>    - Basic layout
>    - Simple markup courtesy of Pango
>
>    Things left to implement are:
>
>    - Animated images
>    - Full markup support
>    - Visual representation of urgency levels
>    - Animations/slide ins/etc. Right now they just appear.
>    - Positioning the notifications so they don't overlap the panels.
>      KDE has some code for this in a generic NETWM class we may steal :)
>    - Currently doesn't do anything with app name/icon. Not really
>      essential

Mine too, it support all what KPassivePopup support (image, summary, body)
the QT markup (include <b> <u> <i> and even more, i'm not sure about links)
and action with links, like Kopete.

It does not support images list, urgency levels, doesn't uses app name/icon 
neither.  And the popup graphism may be improved


> Here are some of the known issues with version 0.3 of the specification:
>
> - Having expiry times given as seconds since the epoch allows for
>    accurate timing (for countdowns and such) but suffers a nasty race
>    condition. [...]. If your notification
>    is set to expire in several seconds .... yep, you guessed it. It won't
>    appear.

I imagined to start counting when the popup appears on the screen

I guess in most usages, never or default will be used.  and if not, it's more 
like a hint  (long or short)


> - Actions should perhaps not be optional. If your program is relying
>    on feedback from the notification it might cause some pain to be
>    able to do without it.

I was about to ask that in my previous mail, ....

>    On the other hand, making a notification server a hard dependency of
>    your application is probably a bad idea anyway. There's no guarantee
>    the user will have it set up and running.

... but because of this, i finaly didn't


>    I think there is at least one KDE hacker interested in implementing
>    this spec already, though I don't know their name.

That's probably me  :-)

>    But, the plan would 
>    be to simply make it an additional part of the KNotify server. So,
>    KDE apps would continue to use KNotify but KDE would still accept
>    notifications compliant with this specification.

Yes, and KNotify will uses that new deamon, so KDE application will be able to 
show better popups in antoehr desktop.

> - Should markup be a required feature? If not, should it be stripped
>    client side or server side? No strong feelings either way on this
>    but currently neither the client lib nor server in the reference
>    implementation do anything with markup.

In my implementation, i let QT handle that.  it will autodetect if it's an 
"html" string or not.
that has the disaventage sometimes text which should be escaped is not.

> - The "FOO or NIL" idiom used in the protocol may not be something
>    DBUS and/or bindings are really designed for .... not sure.

Oh, if it is possible to remove that, i'll be Happy.
Like i said in the previous mail, it will make possible the uses of a DCop 
bridge.


> - The spec doesn't really address error handling in any meaningful
>    way. [...]

good idea.

> - The protocol doesn't currently let you specify the primary frame
>    for animations (is this overkill? do people want animated
>    images?) even though the spec talks about it.

Animations may be great.

> - Do we *really* want more tags than just bold, italic, underline and
>    hyperlink?

In pratice i don't think it is needed.
QT handle a lot of more tag like <table> 

Maybe <pre>  could be nice also ?

about <a href="">,   what protocol do we accept?
Common like http, ftp, mailto, ....  which open the default browser / mail 
client /....
I also thought about an action:/   which emits the invoked signal   (put 
actions dirrectly in the message body)

> - Do we need to specify UTF-8 encoding for strings or do we get this
>    for free as part of using DBUS?

we get this for free with DBUS

--
-------------- 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/20040916/67fe42f2/attachment.pgp