Desktop Notifications Spec 0.3
ogoffart at tiscalinet.be
Thu Sep 16 14:33:12 EEST 2004
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
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+
> - 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
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
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
> - The spec doesn't really address error handling in any meaningful
> way. [...]
> - 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
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
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
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20040916/67fe42f2/attachment.pgp
More information about the xdg