Re: Fwd: Re: Request for Comments: GNOME Notifier
- From: Olivier Goffart <ogoffart tiscalinet be>
- To: Franco Catrin <fcatrin tuxpan com>
- Cc: chipx86 gnupdate org, kde-core-devel kde org, desktop-devel-list gnome org
- Subject: Re: Fwd: Re: Request for Comments: GNOME Notifier
- Date: Fri, 30 Jul 2004 21:42:23 +0200
Le Vendredi 30 Juillet 2004 19:46, Franco Catrin a écrit :
> El vie, 30-07-2004 a las 08:54, Olivier Goffart escribió:
>
> [...]
>
> > The notification protocol need to be extendend to receive following
> > flags:
> >
> > -A bitmask, or a string list, containing what action needs to be
> > preformed (play a sound, show a passivepopup, a message box, blink the
> > taskbar entry, raise the window, log to a file, execute a program, ....)
>
> Those are implementation details in the server. I think that the
> specification is about what is in between the client and the server and
> not how a server will make the actual notification.
>
> For example, a GNOME notification system user interface will be ruled by
> the Human Interfaces Guidelines, and KDE notification server will be
> ruled by their own usr interfaces guidelines.
With the actual KNotify, you can configure every event, and enable or disable
sounds / popups / others for every notificaiton you want (with kcontrol for
example)
Configurable or not, some action make more sens with some events than others.
It would be bad to display a popup when you minimize a window (this event is
handled by KNotify)
And it is quite useless to play a sound when the multimedia player start
playing a track.
So the client need to tell to the deamon what operations should be performed.
> > -The Window Identifier of the originating window, used if we need to
> > blink the task bar entry or raised.
>
> This make sense for me. But I would only use it to blink the taskbar
> entry. In this case there is no point in implementing this blink in the
> client.
It should be done in the deamon, because things like blinking task bar might
be WM specific.
> > -The name of the file where the event may be logged.
>
> Again, that is an implementation detail. It can use the application
> name to look up for a filename or entry name in a log file.
Could be.
KNotify let the user the choice of the filename, and even to select a
different filename for each.
I assume here all the event configuration stuff are handled by the client. So
if we want to made the event logged in a particular file, we have to send it
to the deamon.
Or we could perform the logging operation in the client library.
> > -The program name which should be executed, after some prosessing (for
> > example, %s is replaced by the message in knotify, %a by the applicaiton
> > name, ....)
>
> I don't understand this point
If you have a KControl on the hand, go to the notificaiton page in more
option, and see the context help (maj+f1) of the "execute a program" option.
But, like logging, that does not depend at all of the desktop and could maybe
be performed in the client.
> > I'm not sucribed to the desktop-devel-list, please keep me or
> > kde-core-devel in CC. (or move the thread on xdg freedesktop org ? )
>
> I vote for moving to xdg
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]