Re: Request for Comments: GNOME Notifier

[Mike Hearn <mike navi cx>]

On Fri, 30 Jul 2004 11:27:14 +0200, Lubos Lunak wrote:
>  Yes, the semantics don't quite match as far as I can tell. And after
>  reading
> the "backwards compatibility" section talking about KNotify I have a
> slight suspicion that you misunderstood how KNotify works (because I
> just don't see what the contents of that section have to do with
> KNotify). I'm not KNotify expert, but it works roughly like this:

Yes, that section needs to be rewritten (or scrapped). It'd probably be
easier to just use KPassivePopup directly, but I haven't actually tried
implementing that yet so that might be a bad idea too :)
 
>  The only usually used function is KNotifyClient::event(), if you grep
>  e.g.
> Konsole, that's the only one it uses. When an app wants to notify about
> some event, it simply only calls event() with event type and event
> message. There are configuration files specifying default presentation
> type for each event type. When knotify daemon receives notification
> event, it checks the configuration and represents the event according to
> it. If the user wants a different kind of notification for some events,
> they can go to KControl or in the app in menu Settings->Configure
> notifications, and can change it or turn it off completely.

Yes, KNotify is really a more generic system. I'm not convinced that's
necessarily a good thing though - having configuration files and such for
mostly passive notifications like "You've got mail" seems rather
heavyweight to me. I can see what motivated that, but IMHO such things
should definitely be optional. Config files for how an event should be
presented should be an implementation detail of server policy, rathen
than a formal requirement of the spec.

>  I said I'm no KNotify expert, but although the proposal has some things
> KNotify doesn't, like the feedback, it seems to be less flexible to me
> than KNotify.
> 
>  With KNotify, if KFoo by default uses passive popup and a beep-beep
>  sound for
> even "foo happened", I can turn it off, change it to a normal dialog or
> just make the apps taskbar blink if I want, simply because the app only
> does event( "foo happended event", "Yes, it did."), and the framework
> handles the rest. In the proposal it's the app specifying the sound or
> urgency (and I don't see it talking about any other form other than
> passive popup)

I don't think there's anything in the spec which precludes other
presentation styles. You could have, eg non focus-stealing message boxes,
or Proteus style translucent squares, or marquee tickers in a panel applet
etc.

We did talk about having support for flashing taskbar icons etc, but came
to the conclusion that it's better done by the client using EWMH hints -
or whichever it believes is appropriate.

> so if I want it differently, I out of luck. It should be simple to add
> it to the proposal though.

Bear in mind that things like images, audio and such are entirely optional
and not required by the spec for precisely this reason, my personal
opinion on this is that it'd be best to keep the spec itself as vague as
possible with respect to server policy.

Christian has mentioned having
"notification classes" which are just ways to categorise events into
certain types. I think we also talked about having the app optionally
identify itself.

Therefore, if the server had some information on the source of the method
call, a KNotify style system with config files and a global event
management GUI could be implemented (or, better, just adapt KNotify: 

>  That said, if you want to have a generic system, shouldn't this
>  discussion be
> moved to the xdg@ mailing list? There was a similar thread on
> kde-core-devel@ recently, so probably there should be some KDE devels
> interested in this.

Yes, it probably should. We've held off proposing it there as we wanted to
get feedback in private from people like chat client authors, people who
have implemented systems like KNotify etc, but as these sort of threads
keep popping up perhaps we should just go ahead and propose it :)

thanks -mike