Notifications system discussion

Mike Hearn mike at navi.cx
Sat Aug 7 19:18:27 EEST 2004


A few thoughts:

- On flexibility vs consistency, X has often been criticised by people for
not specifying a widget toolkit as part of the protocol because it led to
multiple toolkits on the same desktop so inconsistency. But, it also gave
much greater freedom to toolkit designers, and today we have great
toolkits like Qt, GTK+ and XUL. On platforms where toolkit and windowing
system were tightly interwoven - like MS Windows - people invented their
own toolkits anyway and you still got inconsistency.

- On audio playback: both WAV and OGG are container formats. They can
contain very many codecs, so you have to start specifying stuff at the
codec/bitstream level etc and it gets complicated fast. If you leave the
client to deal with that, that complexity is avoided. If there are device
conflicts, well this is a bug which should be fixed rather than hacked
around in specifications :)


I think this discussion can be summarised at follows:

- The proposed spec tries to avoid affecting the design of a desktop and
keeps policy either undefined or in the client

- KNotify keeps policy in the server and by design affects the way the
desktop works (by requiring you to have a big central treeview/control
panel type thing for configuring events).

So we seem to be at an impasse. I still have very big doubts about needing
config files to trigger events (which only seems to be needed so you can
configure events before they happen), and even about the UI implications
of such centralised configuration.

I have no idea if a KNotify-style system would be accepted by eg, Gnome,
as I'm not really involved with that project. From my understanding of
their usability guidelines though, the answer would be "probably not" as
they tend to frown upon very generic centralised UI like that. But perhaps
I'm wrong.

I don't know where we go from here. Does anybody else have input?

thanks -mike




More information about the xdg mailing list