Notification spec issue: Ability to assign an icon *and* an image to a notification
Aurélien Gâteau
aurelien.gateau at canonical.com
Fri Jun 26 08:12:50 PDT 2009
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.
> (and btw, regarding the "compatibility", we are breaking the one in KDE.)
True, but this breaks compatibility of a component which
- is not documented
- is hidden, since all applications talk to it through kdelibs/knotify
- has been modeled to closely match the galago spec whenever possible
> The reason we did not use the specification as it is in the first
place is
> because it was not suitable. So the specification need to be changed
and the
> compatibility need to be broken. (You can keep a compatibility layer
in the
> 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.
Aurélien
More information about the xdg
mailing list