Notifications system discussion

[Lubos Lunak]

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 
consistency.

>
> - 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 
file.

>
> 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 
mistaken.

 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 
this:

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 
IIRC).
- 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?

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
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/