Notifications system discussion
l.lunak at suse.cz
Tue Aug 10 16:54:02 EEST 2004
On Saturday 07 of August 2004 18:18, Mike Hearn wrote:
> 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.
I fail to see your point here. KNotify offers both greater flexibility and
> - 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 :)
This is not video playing with its zillion codecs, this is just support for
doing beeeeeeep. Do you really expect somebody would provide such sounds in
some obscure format?
Moreover e.g. the .desktop file spec doesn't specify any technical details
about Icon= yet I don't remember ever hearing about somebody having problems
with their png icon.
> 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).
Could you please read again the so-called "KNotify spec v0.1" in my mail and
point out where exactly it specifies the design? As far as I read it, one
could also say that it tries to avoid affecting the design of a desktop and
keeps policy either undefined or in the server.
If you don't like the word "presentation" used in it, just replace it with
"type" or "priority" or whatever. I seem to remember already seeing those
words in one mail.
> 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.
So you don't like the KNotify's UI? Fortunately that's no problem. Make your
own which will work per-app and will therefore handle only the one matching
> 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.
That's a rather weak argument. Moreover, if they don't like the UI as well,
they can have yet another one.
> I don't know where we go from here. Does anybody else have input?
Yes, that'd be nice. So far it's been only the four of us if I'm not
I have a suggestion where we could go from here. Since it seems we have only
these two proposals, we could make a table listing cons and pros, and then we
can go comparing and trying to meet in the middle.
Just make something short comparing your spec and KNotify. Something like
KNotify bonus points:
- KNotify is an already existing and working solution. The spec is not. (Ok,
KNotify needs some extending).
- KNotify allows you to configure all apps the same way (meaning the same set
of presentations for all apps). With the spec it's possible apps will
hardcode one way with any possibility to turn it off, or similar.
- Apps using KNotify don't need to link to a bunch of sound/presentation libs
just in order to do something as simple as beeep (ok, this is not really that
important, but it was actually the reason KNotify was originally created
- Since almost everything is in the server, you can easily handle new problems
with cases like screensaver active or similar. With the spec you have only
one type of notification, so all others are done in apps and you have to fix
all of them.
KNotify penalty points:
- KNotify needs somehow to find out list of possible events for apps and some
details about it (config files, or something else, but I have no other idea).
Some things you might possibly expect in the KNotify penalty points sections,
but they don't belong there:
- Centralized UI - Select Configure->Configure notifications e.g. in Konsole
to see it per-app.
- Restricts types of presentations, restricts UI, whatever - KNotify spec
technically doesn't need exact representations specified. Just specify type,
importance or whatever.
- More complicated - With the exception of parsing the default config files it
should be roughly the same.
So, how about your list?
SuSE CR, s.r.o. e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27 tel: +420 2 9654 2373
190 00 Praha 9 fax: +420 2 9654 2374
Czech Republic http://www.suse.cz/
More information about the xdg