Notification spec issue: Ability to assign an icon *and* an image to a notification
Aaron J. Seigo
aseigo at kde.org
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
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
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/xdg/attachments/20090624/1d07b907/attachment.pgp
More information about the xdg