Notifications system discussion

[Lubos Lunak]

Dne so 31. července 2004 19:30 Mike Hearn napsal(a):
> On Sat, 31 Jul 2004 17:03:52 +0200, Lubos Lunak wrote:
> > So it will probably show a passive popup and play the sound, which,
> > oops, I dislike. I don't care if disabling passive popups would or would
> > not be against GNOME usability ethos, but I want to be to able to
> > disable them in KDE. But as I said KNotify has no clue about GFoo, so it
> > won't even let me to change it. Even after adding the suggested .desktop
> > file name KNotify will know there is GFoo, but will not know about the
> > foo event. Bummer.
>
> If you dislike a particular presentational style, why not change it once
> for all such incoming events rather than configure it on an app specific
> and even event specific level?

 Ok, let's change the assumption a bit. I hate passive popups in general, but 
I'd still want to have them for very important things like "You're running 
out of disk space." or "The system will reboot in 2 minutes."

>
> I'd note that there's nothing preventing you from patching GFoo to
> configure how it notifies you of events inside GFoo itself

 Uhm, you're kidding me, right?

> : in any case, 
> maybe this is better as the app itself can provide a far tighter and more
> focused UI than a totally generic one can.

 "tighter and more focused UI" == random collection of checkboxes varying in 
every application as opposed to one standard dialog?

>
> Nonetheless, I guess it would not be hard to have some kind of event ID
> to identify particular types of event, so you have a (app id, event id)
> pair that you can use to override the clients requests inside KNotify.

 That still doesn't help me much if I don't know the list of event_id's while 
configuring it.

>
> >  You probably think KNotify is some complicated monster, but it's
> >  actually no
> > rocket science. Current KNotify implementation is less than 1000 LOC.
>
> How big the KDE implementation of KNotify doesn't really concern me to be
> honest, what concerns me is:
>
> a) How difficult it is to specify formally

 KNotify spec v0.1:
 [Note this does neither describe KNotify precisely not it's a real proposal. 
I'm just making this up to have some kind of a spec as well comparable to 
yours.]
 Applications wanting to notify the user about certain events (such as new 
mail, low disk space, buddy online, whatever) can use the following DCOP call 
to inform about the event:
 DCOP client: knotify
 DCOP interface: Notify
 DCOP call: int event( QString appname, QString event_name, QString 
event_details, QStringList actions, WId window);
 
 appname - the application, i.e. "kmail", "kopete", whatever
 event_name - name of the event, unique in the app, e.g. "NewMail", 
"LowDiskSpace", whatever
 event_details - text describing the event, e.g. "You have 2 new mails.", 
"There is only 1MiB free disk space on device /."
 actions - List of actions the user can take as a result of the event. It is 
not guaranteed the user will be presented with these possibilities in every 
presentation style. The application will be informed about the result using 
the DCOP signal eventDone(), see below.
 window - X id of the toplevel window related to this event
 
 The number returned from event() is a unique id of this specific event 
notification.

 DCOP signal: eventDone( int id, int action )

 This DCOP signal is emitted when the notification has been dealt with 
(dismised, action was chosen, ignored, whatever).

 id - id of the event notification, as returned by event()
 action - action selected by the user, from the list of actions specified in 
the event() call, the number is the position of the action in this list, 
starting from 1, or 0 for no action

 In order to allow configurability of presentations for the specific event 
notifications, every application should include a file describing its 
possible events, located in /somewhere/events/, named as <appname>.events, 
with the following format:
 The file format is the .ini style format, used e.g. also for .desktop files 
[copy&paste here the details]:

 [!Global]
IconName= icon of the app, see icons spec
Comment= comment describing the app
<list of sections, each named as the event>
[EventName]
Name= description of the event
DefaultPresentation= default presentation, number, bitfield from the following
  0 - no presentation
  1 - sound notification
  2 - very intrusive notification, e.g. a dialog box
  4 - less intrusive notification, e.g. a passive popup [still considered 
intrusive because it takes some screen space]
  8 - unintrusive notification, e.g. blinking the taskbar entry, or using a 
special panel area reserved for notifications
 ... - whatever
[Note it doesn't really talk about any specific presentation, it just vaguely 
specifies kinds of them. Perhaps this doesn't even need to be so 
fine-grained.]
  In case the notification daemon doesn't implement some of the presentation 
styles, it may remap them to the ones it does implement. It's recommended to 
go towards the less intrusive types.
DefaultSound= default sound file to play in the case of sound notification

 That should do. Feel free to add "shall" enough times to make it sound formal 
enough.

>
> b) How much effort it would take to implement such a spec inside other
> desktops (not just gnome, I'm not a Gnome developer and neither is
> Christian)

 Piece of cake with kdelibs. I can't tell for others.

>
> c) Keeping it very straightforward to understand for the developer

 You mean for the app developer? "Create a file with this simple format, and 
do event( ... )."

>
> > Aditionally it creates a file describing its event types and puts in in
> > a standard location.
>
> Yes, this is one problem I have with the KNotify approach, I don't
> think having to install files in order to do a passive notification is a
> good plan. It's yet more things to spec out (file formats, etc), means
> that only "installed" apps can use the service as opposed to things like
> shell scripts etc, and generally increases complexity.

 Shell scripts, unless written by the user, are also "installed". For the 
rest, perhaps just having the daemon deal with unknown apps in any way it 
sees to fit could solve this.

>
> Likewise, specifying presentation as part of the system makes it harder to
> add interesting new presentational styles in future.
>
> But basically if we were to add the app desktop name and allow apps to
> specify event IDs, this would provide closer semantics to KNotify: the app
> specifies the contents of the notification in the message and the server
> can choose whatever notification it deems appropriate. In the KNotify case
> it could let the user configure each event in each app specifically.

 Sorry, still insufficient. No way to configure no notification at all for 
"XYZ is online", taskbar blinking for "You have new mesage" and passive popup 
for "You have a file transfer pending" from one IM client.

> >  Why exactly are those better done client-side, other than it being
> >  possibly slightly simpler to do?
>
> Because it makes the spec simpler and gives extra flexibility as you are
> not constrained by what is expressible in the protocol.

 I beg to differ. The spec is not significantly simpler (if it is at all), and 
it doesn't give any flexibility (unless you equal inconsistency with 
flexibility).

> For instance, 
> playing a sound: what formats are supported?

 wav, ogg. Who needs more?

> what media frameworks are used?

 Who cares as long as the sound is played?

> what if you want it to repeat? All these questions disappear if the 
> app does what it wants directly, instead of asking something else to do it.

 And new questions appear:
- what about the inconsistency?
- what if the media framework which the app would use wouldn't work (say, 
because some other is blocking the device)?
- what about the lesser flexibility?
- what if I hate passive popups and don't find it funny I'd have to modify and 
recompile GFoo?
- what if my screensaver kicks in and the notification done client-side goes 
unnoticed?
- what if my desktop gets a new very good way of notifying, but it's as 
useless as a fith wheel because the app still insist e.g. on just blinking 
its taskbar entry?

 I don't find one IPC call more complicated than having the notification 
daemon code in every app.

> >  This must be a misunderstanding. KWin has an event called "minimized"
> >  (or so)
> > which has a default presentation in the form of playing a short sound,
> > but the actual minimalization is handled by KWin of course.
>
> Yes of course, what I meant is that KNotify is clearly handling a lot of
> different notification types: this spec is meant for coarse-grained
> async (ie not triggered by the user) events that don't happen very often
> and are supposed to grab the users attention when they do. So "you have
> mail" or "you are running low on disk space" would qualify but "user
> clicked a button" or "user minimized a window" would not.

 I see. But why should you limit yourself to inventing new inferior solution 
when a more powerful solution already exists, and is not significantly more 
difficult?

-- 
 Lubos Lunak
 KDE Developer