Notification spec issue: Ability to assign an icon *and* an image to a notification
Brian J. Tarricone
bjt23 at cornell.edu
Sat Jun 27 01:44:20 PDT 2009
On 2009/06/26 18:05, Aaron J. Seigo wrote:
> On Friday 26 June 2009, Brian J. Tarricone wrote:
>> I'm honestly not trying to be inflammatory here; I'm just trying to
>> understand *specifically* what it is that you can't do with the existing
> in a nutshell:
> knotifyd stores descriptors for all registered notifications. this allows the
> notifications to be managed, configured and controlled without requiring the
> target application to be active (though you can also configure the
> notifications from within the application, of course).
> applications activate notifications by their identifier (+ any specific-to-
> that-instance-of-the-notification data), and knotifyd handles the routing from
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.
> 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-
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?
> 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.
> * extensibility
Galago could be considered 'extensible' by way of new hints, but yes,
that's pretty minimal.
> * 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?
> the part of the notification system knotify takes care of is pretty orthogonal
> to the part that galago does.
I'm still not really seeing it. I certainly see how knotify is very
different from current galago *implementations* (such as
notification-daemon), but I don't see why you can't implement most of
knotify using galago's interfaces. The galago server would act as more
of a middleman, deciding what to do with notifications and passing them
on to something else (or multiple something elses) that wants to do
something with them.
I imagine some things are missing... like in an old blog post,
Olivier talks about being able to set a per-contact sound to play when
that person IMs you. I don't see a way you could do that with current
galago without some extensions added. (Personally I don't think this
particular feature belongs in the notification system, but instead in
the app generating the notification, but that's certainly debatable...
and I imagine there are other nice features like that which are
difficult to do with current galago.)
And then you could add registration of event types, and stuff like that,
without making the current galago bits still useful (that is, apps that
don't know about the new protocol extensions will still continue to
work, just without support for the new stuff).
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...
> 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...
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?
> i hope that clears it up somewhat.
Yes, it does, for the most part, thank you.
More information about the xdg