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

[Aaron J. Seigo]

On Saturday 27 June 2009, Brian J. Tarricone wrote:
> On 2009/06/26 18:05, Aaron J. Seigo wrote:

> > applications activate notifications by their identifier (+ any
> > specific-to- that-instance-of-the-notification data), and knotifyd
> > handles the routing from there.
>
> Ok, so this sounds a lot like Nofitications.Notify()'s app_name
> parameter ("their identifier") plus category/urgency hints ("specific...
> data").  The fact that app_name is optional is potentially problematic.

an app can have more than one notification, so it's more than just the 
app_name. it's the app_name plus a unique (to that app) identifier for the 
notification that can be referenced even when the application isn't running.

the documentation for KNotification on api.kde.org captures all of this.

> > it also allows for more than one simultaneous visualization of the
> > notification as it can serve as a repeater to and state-holder for other
> > sub- systems.
>
> What's keeping a galago server from also acting as a repeater to send
> notifications to other apps speaking a private (or other public) IPC API?

nothing, other than that's not what they do right now. probably because that 
has never been part of the design goal.

> > so the benefits are, in a nutshell:
> >
> > * management
>
> What other things does knotify allow you to manage that galago doesn't?
>   You could route notifications somewhere (visual, speakers, log file,
> IM network, carrier pigeon, /dev/null) based on app_name, urgency,
> category, or any new hint you might want to dream up.

and where do we find these names, urgencies and categories? at runtime, when 
the notification occurs. which means that we either have the users play a game 
of reading the mind of the computer (with such unuser-friendly things as 
app_name.. oi!), set up filter settings only when they happen (a little late 
in most cases) or have the applications describe their notifications 
beforehand and set up a system to manage that ... which is what knotify does 
and which galago doesn't.

now, i don't think that's a knock on galago. it really isn't the same kind of 
system that knotify is, and vice versa. i expect to see differences. and i'm 
not keen on making square blocks fit into round holes :)

> > * extensibility
>
> Galago could be considered 'extensible' by way of new hints, but yes,
> that's pretty minimal.

not just minimal, but also visible to the client. knotify can be modified  
(e.g. as we did with the galago sec addition, though that's really a trivial 
example) without it being visible to the applications using it in the least. 
that kind of separation between components is very useful.

> > * flexibility in notification target behaviour (e.g. multiple
> > visualizations)
>
> Does knotify provide a way for client apps to attach a larger set of
> semantic metadata than galago?  What kinds of things if so?

currently contexts and standardized events. contexts are a bit weaker than i 
think they could be right now in that we don't use them for much at this point 
in time. but yes, the system is well set up to add additional information, and 
depending on the information without having to send it over the dbus.

> But I guess if you add all this, then you end up turning galago into
> knotify with a different API, as you suggest below, but...

right, and then you end up still wanting something to go between this new 
thing and the hosts for visual notifications (as they may not be in the same 
process as the notifier daemon, for instance).

this also ignores the fact that there is already a working implementation of 
this part of the system out there. so if we grow galago into knotify, we're 
making everyone write code and we will be breaking KDE code that will need to 
get updated. whereas if we work knotify's dbus spec into something we can all 
use, then galago-only app platforms can elect to implement that new bit 
(something they'd have to do anyways) without incurring additional work.

there's also something to be said about adopting a system that's been proven 
to work versus trying to shape something else into an analogous system from 
the ground up.

i just don't think the "grow galago" concept makes much sense in light of all 
that. i think we ought to let it be what it is and do what it's good at.

> > now, what Olivier is referring to is that galago addresses one subset of
> > what the entire notification system should be capable of doing. some
> > applications are just fine with that, but really they are talking about
> > visual notification when they say "galago". we certainly could extend
> > galago to handle more use cases, but eventually we'd recreate knotify
> > (and change how applications use galago; i don't think it could be done
> > in a purely backwards compatible way) and, once again, need a "new
> > galago" to do what galago is doing right now for us (communicating
> > between knotify and the visualization(s)).
>
> ... that raises another question: what exactly is your goal with this?
> It seems like you guys are really happy with knotify.  Are you merely
> interested in creating some kind of middle cross-desktop layer that any
> app (written for any desktop) can use such that it gets forwarded on
> properly to the desktop's native notification system?  I would certainly
> not expect that you'd want to replace knotify...

two things:

a) with galago, harmonize the visual notifications that are used by different 
toolkits; this way a KDE app running in [GNOME|XFCE|LXDE|*] will use whatever 
visual notification display system is there and vice versa.

b) now that knotify is using d-bus, get a spec out around that so that others 
may also adopt that part of a notification system if they wish

> Otherwise I'm not sure I get it.  The features being discussed here (at
> least the one in the subject line of this mail thread) over the past few
> days certainly sound worthwhile, but it all still amounts to a subset of
> what knotify offers, right?

correct; in the context of the "what galago does and probably ought to do" 
discussion, it's been kept to a subset of knotify.

so the discussion about the galago spec API has been to ensure it can work 
with knotify properly without it resulting in a degradation of service for 
visual notifications in KDE.

the discussion about the galago spec service name .. well, that's something 
slightly different.

-- 
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/20090627/ba2adf27/attachment.pgp