Notifications system discussion
l.lunak at suse.cz
Sun Aug 1 15:49:26 EEST 2004
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
> > 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
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",
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
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]:
IconName= icon of the app, see icons spec
Comment= comment describing the app
<list of sections, each named as the event>
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
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
> 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
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
> 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
- what if my screensaver kicks in and the notification done client-side goes
- 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
More information about the xdg