galago notification spec (Was: JobViewServer specification proposal)

[Olivier Goffart]

Le mercredi 2 avril 2008, Aaron J. Seigo a écrit :
> On Tuesday 01 April 2008, A. Walton wrote:
[...]
> and now on to the galago spec:
> > And it just so happens FD.O already has a specification for
> > notifications [1], a daemon and client implementation, and it's well
> > adopted code in the GNOME community (I can't speak for the KDE side of
> > things).
>
> the plasma project recently started working on a mechanism to export via
> d-bus notifications that are intended to be shown as popups via d-bus from
> knotify out to the UI via this spec, as well as creating a plasma based ui
> to display such notifications.
>
> it's based somewhat on the org.freedesktop.Notifications.Notify spec, but
> there are points of the spec that we would like to improve on.
>
> what we have works nicely, and if we can get the spec in order, then
> hopefully in the near future (e.g. 2008, either the july or dec release)
> kde notifications can be exported to the GNOME ui, and GNOME apps can use
> the the plasma notification area. yay!
>
> so... to thread hi-jack this for a discussion of the galago spec (sorry!) a
> non-exhaustive list of areas where we'd like to improve the spec include:
>
>
> Basic Design: http://www.galago-project.org/specs/notification/0.9/x81.html
>
> Issue: it's not clearly described what the "notification server" is
> responsible for. it does say that it is optional, however.
>
> Proposal: clarify the language to define the scope and purpsoe of the
> notification server more clearly. e.g.: "The server is responsible for
> displaying the notifications to the user in a device and use case
> appropriate manner. While the server may make decisions at to how and which
> notifications to actually display, it is not responsible for configuring
> user notification preferences for the client application."
>
>
> Icons: http://www.galago-project.org/specs/notification/0.9/x207.html
>
> Issue: the iibiiay format seems a bit overspecified.
>
> Proposal: always use argb32 data.
>
> Issue: this part of the spec seems generally underspecificied. there is no
> reference to how icons referenced by name are resolved (the theme and
> naming specs) to name one.
>
> Proposal: remove this page entirely. all relevant information on icons can
> be found elsewhere in the spec. duplicating information in this way just
> begs for inconsistencies over time.
>
>
> Urgency Levels:
> http://www.galago-project.org/specs/notification/0.9/x320.html
>
> Issue: having low/normal/critical as the only options may be ok for the
> immediate, but room for likely future growth should be taken into
> consideration. as such, having this in a byte with the values Low=0,
> Normal=1 and Critical=2 makes this very difficult.
>
> Proposal: Distribute Low, Normal and Critical across a wider range, e.g.
> Low = 0, Normal = 127, Critical = 255. this way new values can be added and
> implementations could still work with a simple less than comparison of
> urgency level.
>
>
> Hints: http://www.galago-project.org/specs/notification/0.9/x344.html
>
> Issue: desktop-entry contains the literal name of the .desktop file. for
> multiple versions of the same application coinstalled (e.g. a kde3 and a
> kde4 version) this creates an ambiguity.
>
> Proposal: use the storage identifier that can uniquely identify the app;
> though i don't see that concept in the fd.o specs? perhaps that too needs
> to be added ... but it allows us to e.g. disambiguate kde3-kcalc from
> kde4-kcalc.
>
> Issue: image_data seems a overspecified.
>
> Proposal: always use argb32 data
>
>
> Issue: sound-file ... we actually handle sound elsewhere in our events
> system. The spec says the sound is to be played "when the notification pops
> up." Well, there's no guarantee of a popup at all here.
>
> Proposal: Separate sound from visual cues in the spec. There is no such
> strong linkage.

As I understand it, the point of the specification is just precisely to show a 
popup. (would be the equivalent to advanced KPassivePopup in KDE terminology)

Don't be confused by KNotify, which can do lot of different, configurable 
presentation.


> Issue: suppress-sound is superfluous?
>
> Proposal: remove it from hints altogether. if the app is going to play its
> own sound, don't provide anything in sound-file.

This come from previous discution we had on this mailing list.

IIRC The old implementation was playing a default sound if no sound file was 
given.

So this is would have been incompatible with KNotify which play itself the 
sound.

> Issue: no way to relate it to an application window, which is useful for
> taskbar or window effects
>
> Proposal: add an opptional winId hint
>
>
> Categories:
>
> these seem a bit random. i'm sure they made all the sense in the world to
> the authors, but this section could use a lot of work. things like the
> distinctions between email/im/presence could use work, or how device
> notifications are not actually handled by notifications in all systems for
> user interaction reasons, etc. a number of fairly obvious categories are
> also just plain misisng. probably this is mostly due to simply not having
> more users of the notification system and could be worked out over time. it
> would be nice to note this in the spec and make the current list a bit more
> fluid.
>
> i also wonder why it's using '.' as a separate rather than '-' as most of
> our other specs seem to.
>
> the use of x-vendor.class.name seems unnecessary. if there's no consensus
> on the matter then either only one part will use it (and there's no threat
> of collision) or one has to ask themself if it really matters if the
> grouping semantics aren't agreed on. if "x-vendor" is kept, for conformance
> with other specs it should be "X-Product". see:
> http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s08.html
>
>
> D-BUS Protocol:
> http://www.galago-project.org/specs/notification/0.9/x408.html
>
> org.freedesktop.Notifications.GetCapabilities
>
> Issue: it's odd that the possible server capabilities are defined on this
> page, whereas all other such listings (categories, hints, etc) are defined
> on their own pages.
>
> Proposal: Create a Server Capabilities page after section 8 Hints and move
> the listing there.
>
>
> org.freedesktop.Notifications.Notify
>
> Issue: app_icon is not necessarily appropriate for a given notification. it
> is defined as "The optional program icon of the calling application." the
> other option is to use the icon_data hint instead and ship raw data.
> there's also abiguities as to the related to icon_data, where this icon is
> defined, etc.

icon_data and app_icon are different:
Take the Kopete online notification : app_icon is the kopete icon, while 
icon_data would be the user's avatar.

> Proposal: "The name of the icon to show in association with the
> notification, such as the application icon. The icon name should be
> accessible via icon theme loading as defined in the freedesktop.org Icon
> Theme and Icon Naming specifications {link to urls}. Alternatively, image
> data may be passed via the icon_data hint {link to description of hint}.

but that proposition make sens.

> 9.2 Signals
>
> do we really need these signals broadcast to all applications? esp when we
> get to long running jobs with updates, it makes sense to reply directly
> back to the calling object since traffic can get pretty high in both
> directions.
>
>
> i'm probably missing things, but that's a good starting point for
> discussion.
>
>
> (btw, i find it a bit cheeky to namespace a dbus interface in
> org.freedesktop when there has been essentially zero actual freedesktop.org
> processes put to it. interfaces should either start with cross project
> involvement from the start or namespace themselves to the project. any
> other approach risks poluting org.freedesktop needlessly.)
>
> > Not a lot needs to change to make this
> > happen either: to make the notification not expire until we want it
> > to, set the expiration timeout to 0, a new hint needs to be added
> > "progress", which indicates how far along a current job has progressed
> > (obviously), the "categories" should really have some more generic
> > "long running task" category, such as "Job", and the addition of a few
> > methods to make it easier for application developers to update
> > existing notifications such as GetNotification and ListNotifications.
>
> and add speed, total amount ("450 images", "300 Mb", "3 filters") ...
> there's more to it than immediately meets the eye, and a lot in the
> notification spec that is not overly relevant to job listings.
>
> there's obvious similarities, but i'm not sure the similarities justify a
> unified spec.
>
> > So then applications just need to be able to hold on to, or get hold
> > of, the notification-related information and send notifications to
> > update the current one when necessary. The standard facilitates this
> > with the "Replaces ID", which I've found to be sufficient in the work
> > towards this that I've done.
>
> .. and then get back a new ID that you then have to hold on to each time on
> the client side, essentially mapping an internal id to an external one
> that's constantly changing? and heaven forbid the replies should ever get
> out of order with sends (e.g. this would need to be synchronous). this
> seems very hackish. you don't want to replace anything, you want to be
> updating something.
>
> > Of course, the current implementation of the notification-daemon is
> > near useless; you can't hide/reject notifications from parties you're
> > not interested in, you can't get a history of notifications,
>
> this is all implementation side, of course, and not particularly
> interesting to the spec.
>
> > and
> > there's no way for applications to get a list of other open
> > notifications nor a specific notification
>
> you mean specific to that app.. but then how would you control that? trust
> the app? sounds like a great way to open the door to leaking information
> from one app to another ...
>
> > shame. These are all specific defects in the existing code and
> > standard that are barriers to entry which are very easily overcome,
> > it's just a matter of sitting down and doing the work.
>
> well, i think this lists mostly defects in implementation which aren't
> particularly of interest here.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/xdg/attachments/20080402/c72e7fb4/attachment.pgp