Notification System

[Esben Stien]

Mirco Müller <mirco.mueller at canonical.com> writes:

> The reason for this is to avoid the user being spammed by
> notifications coming from "misbehaving" applications.

That's solvable by another abstraction layer. If the daemon displaying
the notifications had some rule system, this could be done here, along
with a great deal of other juicy features. 

Applications may send whatever they like onto the general notification
bus. What is actually displayed should be controlled by a rule system. 

> Being action-less helps making notifications ephemeral and not getting
> in the way of the user. The user will not be urged to click something,
> thus be briefly drawn away from his/her current workflow.

Well, I don't agree with this one. You still would provide means for
urgent messages that requires user input in one way or another. 

> notify-osd deliberately ignores non-zero timeouts, because it is meant
> to be in control how long something is on-screen

This should be user controllable, cause you're definitely not covering
my needs. 

> Zero timeouts (meaning "stay on-screen forever") are an indication,
> that the sending application wants to tell the user something very
> important. For such messages notification should not be misused.

Well, you still would need some sort of notification system. If you
don't want to integrate notifications into a system that can handle all
kinds of notifications, then I would say that's some pretty bad
engineering;).

> This fallback-dialog is meant to cause a bug-report and/or show us
> which application is misusing the notification-system. Then we can
> engage with the application's upstream and suggest redesign of that
> particular notification-use and/or work out a patch.

Well, you still can't escape notifications that are supposed to notify
you of something important and requires the user to jump out of the
comfy chair, stomp the smoke, put the coke bottle down and act. 

> That's some of the rationale behind the design-principles, which drive
> notify-osd.

Well, if your notify-osd system can't notify me, it's pretty useless to
me;). 

> What kind of notification (information) do you want to present anyway?
> Since you want it to stay on screen forever (until you notice it)
> there might be a better way to do so.

Well, a great deal actually. Today I wrote an esl daemon that would
listen for certain extensions dialed on my PBX. On some extensions, I
need to be notified immediately and I need to act on it. I then had this
daemon send a dbus notification. 

Since the smart asses that designed D-Bus didn't include network support
and removed CORBA from GNOME, I now had to transfer the message through
another network protocol. Maybe we should call it GOME, now, instead.

Also, when I watch a video, and the notification sounds are muted, I
need visual blinking messages that doesn't go away. 

Btw, I'm also designing a daemon that would lower the sounds on a set of
channels and turning the gain up on a notification alarm channel, so
that I may get audible notification if I'm not looking at the
monitor. I'll bind the SLEEP key on my keyboard to turn off non
emergency notifications if I'm not to be disturbed. All my audio goes
through JACK, even pulseaudio is a JACK client, so this will also be
quite simple.

I'm also going to write a daemon that send a message to my freerunner
phone via SMS or email. This should only happen when the phone is not
detected via my local wifi network (ie, I'm out). 

-- 
Esben Stien is b0ef at e     s      a             
         http://www. s     t    n m
          irc://irc.  b  -  i  .   e/%23contact
           sip:b0ef@   e     e 
           jid:b0ef@    n     n