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

[Brian J. Tarricone]

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
> 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.

> 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?

> 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[1], 
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.

	-brian

[1] 
http://blog.bepointbe.be/index.php/2006/08/30/18-notifications-in-kde4-with-knotify