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

Aaron J. Seigo aseigo at
Wed Jun 24 10:18:47 PDT 2009

On Wednesday 24 June 2009, Aurélien Gâteau wrote:
> Aaron J. Seigo wrote:
> > On Wednesday 24 June 2009, Aurélien Gâteau wrote:
> >> There are patches for libnotify, notification-daemon, kdebase and
> >> notify-osd.
> >
> > org.freedesktop.Notifications ... *sigh* sorry, but that's not
> > acceptable.
> Most people here seem to prefer the backward-compatible approach, this
> does not allow changing the dbus name. The only solution to this is to
> create a new dbus spec and have existing notification daemons implement
> both in a transition time. I do not see this happening...

changing the name does require a new dbus spec. it requires changing the name 
of the service.

there are two reasons why this is important: 

a) the name is simply incorrect and will leave us with annoyances when we 
actually take on the full topic of notifications

b) there is a community governance issue here that needs to be taken seriously 
if fd.o is to actually remain (re-emerge?) healthy and functioning.

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.

the community governance issue:

this service name under the fd.o namespace was hijacked without consensus, and 
that's simply not on. the implications of "first come, first serve, no 
collaboration needed, forced it on the rest" is completely broken behavior and 
shows a complete disregard for the entire concept of using a shared namespace 
and working towards shared standards. anyone who implemented 
"org.freeesktop.Notifications" did so a their own risk as it was _not_ within 
their purview to simply claim that service name in what is a shared namespace.

consider the ramifications of me going and registering 
org.freedesktop.SystemTray or even org.gnome.SystemTray just because i can. 
that simply doesn't work as a mechanism.

using org.freedesktop.Notifications was a mistake, one that set up an 
absolutely horrible precedent. along with similar irresponsible actions we 
seen over the years here, it threatened fd.o's ability to legitimately be 
called shared and participatory. this is not theoretical: i've had to 
vigorously defend fd.o to certain people in KDE who cite such behaviour, this 
spec being one actual example of it, as proof that fd.o is _not_ collaborative 
and is _not_ in our best interests.

at some point we have to start taking this whole "designing a shared platform" 
thing seriously or else just give up and go create our separate silos, screw 
the user and see who can get to spec definition first, collaboration 
unnecessary, gold-rush style. granting exception upon exception to proper 
behavior in this forum is not productive.

if it's a painful exercise in learning what collaboration actually means for 
those who jumped on org.freedesktop.Notifications, so be it. perhaps in future 
people will take it this all a bit more seriously and exercise responsible 
behaviour instead of laissez faire cowboyism. it would certainly help with the 
legitimacy of fd.o as a shared organ.

> While I agree the dbus name is not completly accurate, it is just an
> internal name, not something users will face.

this particular case has nothing to do with what user sees directly, and 
everything about how to create a shared platform that we collaborate on to 
make something that we can build sane user experiences on top of now and in 
the future.

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 : 

More information about the xdg mailing list