Notification spec issue: Ability to assign an icon *and* an image to a notification

[Aaron J. Seigo]

On Friday 26 June 2009, Aurélien Gâteau wrote:
> Olivier Goffart wrote:
> > Le Thursday 25 June 2009, Aurélien Gâteau a écrit :
> >> What I meant was that if you feel the application is spamming you and
> >> you think most users will feel the same, then maybe talking with the
> >> application developers about this problem would be a good idea.
> >
> > As Lubos wrote, this is again the same useless discussion as few years
>
> ago.
>
> > Can the specification be used to log some notifications, display some
>
> others,
>
> > and play a different sound for some others?  The answer is NO.
>
> True (no need to shoot). That's why I said this:
> >> Yes, knotify gives you more control and I agree different users have
> >> different needs.
>
> The fact that you can't configure notifications individually does not
> mean it is impossible to implement a non-visual notification server
> (think vision-impaired users for example) with this spec.

right, but it's an all-or-nothing or a try-and-filter-based-on-some-fuzzy-
matching approach with the galago spec. it simply isn't built for treating 
different notifications differently or allowing for configuration of them.

that's ok, i don't think the galago spec should be bent in this way. it should 
do precisely what it's doing: notify the environment that "this visual 
notification needs to be made".

now, the major drawback i see in galago is it allows for one visualization 
only since it targets a "well known" dbus address, unless you multiplex that 
in the server and re-emit to N different visualizations.

what would make sense to me is to allow a mechanism by which other 
visualizations can register themselves as listeners to visual notifications, 
each of which would get sent the data. 

in the common case, there would be one listener and everything would be just 
as-is. it is not unusual to expect to show the same body of data, or subsets 
of it, in different places/ways.

that, however, can be done outside the spec with an implementation-specific 
dbus service that takes registrants which speak the same galago dialect.

but then we're getting into something more like knotify. and really, that's 
how galago probably ought to have been designed from the start: an interface 0 
to N objects on the bus can implement to show visual notifications to the 
user, with those objects registering themselves with a well known interface.

perhaps something to take into consideration in a new, full notifications 
spec.

> > original server if you want)
>
> The image + icon problem can be solved in a backward compatible way.
> Other issues like being able to centralize how notifications are
> presented the way it is possible to do it with KNotify right now do
> indeed require a new spec, with a different name.
>
> I believe it's a good short-term move for KDE to switch to the existing
> spec while defining a better, brand-new spec for the future.

there is no need for KDE to switch to anything. we're using the galago spec 
(or a modification of it, currently, hopefully not after your patches go in) 
to relay visual notifications from knotify.

let's not more this difficult than it needs to be by confusing what knotify 
does with what galago does and how we've implemented each in kde 4. i really 
don't want to go through the whole "this is not a replacement of knotify with 
something less capable" thing again with my KDE teammates.

galago and knotify have essentially zero overlap in functionality. in fact, 
knotify provides a notification _system_ that feeds the service defined in the 
galago spec with data to show.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Software

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/xdg/attachments/20090626/32b979f9/attachment.pgp