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

[Aurélien Gâteau]

Olivier Goffart wrote:
> Le Wednesday 24 June 2009, Aurélien Gâteau a écrit :
>> Aaron J. Seigo wrote:
>>> the correctness issue:
>>>
>>> these are not notifications, they are a subset of notifications. what do
>>> we call a spec that actually does notifications? FullNotifications? there
>>> is no point in collaborating if there is no collaboration, and in this
>>> case it's pretty evident that the service is incorrectly named which will
>>> lead to a pretty jangled system later on.
>> In fact I just realized the name can be considered correct. After all,
>> this spec defines a notification as composed of an icon, an image, a
>> title, a summary and a sound. Sure the icon and the image are only
>> visual, but nothing prevents someone from implementing a text-to-speech
>> server which would play the summary, title and sound.
> 
> 
> *NO*
> 
> You fall in the same trap.
> 
> The visual notifications is not suposed to do that. KNotify does.
> 
> That's why it is very important not to use org.fd.Norifications.  So developer 
> does get confused.
> 

In the case of KDE, KNotify takes care of non visual notifications and
delegates visual notifications to Plasma, which implements the spec
(after my patch). This does not mean other implementations can't do
things differently.

I see nothing wrong having the KDE implementation showing notifications
as Plasma bubbles, while another implementation instead logs them to a
file or plays them back with a text-to-speech engine.

>> So, in order to punish people who incorrectly used the org.freedesktop
>> namespace, you want to impose a rewrite to everyone involved? I am
>> pretty sure the author of the Xfce implementation for example has
>> nothing to do with the incorrect use of the namespace. And what about
>> users or third-party developers who wrote scripts or code which show
>> notifications using dbus-send? why punish them as well?
> 
> It is not a big deal.  Modifications need to be done anyways, and changing the 
> name is one line of code of change.

Suppose you are using a library which provides a class named Foo. This
library has been in use for 5 years, but you think the class really
should have been named FooBar. Would you ask the library maintainers to
break binary compatibility to get the class renamed?

KDE developers use the KNotification class, other developers use
libnotify. They don't care about the DBus name. Why change just for the
sake of change, especially since not all parties consider this change to
go in the right direction?

Aurélien