KNotify-considerations for frameworks

[Thomas Lübking]

Am Sat, 24 Sep 2011 13:26:41 +0300
schrieb George Kiagiadakis <kiagiadakis.george at gmail.com>:

> Sounds a bit unrealistic, although I must admit it could be useful if
> you don't have a taskbar and you also have hearing problems...
> 
> But still, think of the minimize event. Configure a popup that says
> "you just minimized your window"? Sounds stupid.
Maybe. What about logging? Running a command?
And what about the popup if it's on another display?

Why precisely do you want to *artificially* restrict the users choice
here?
If a certain notification type is pointless for a certain event, the
users simply won't choose.
Assuming that you will be able to predict all
necessary and/or pot. useful notifications for some event is at least
close to hubris. (as you've apparently just noticed)
But assuming that all app devs will is naive.


Personally i think having a sound on this is completely annoying and
happily switching it off is one of the very first things i do - there's
no message on minimizing etc. on this box.

> >  or have a KWin compositing effect, or whatever else that I haven't
> > come up with but that doesn't mean nobody else can?
> 
> KWin is the app that sends those notifications, so it can also do
> crazy things internally if it wants.
The point is that kwin only yells "notification" and does not
care about how it's handled afterwards.

Not only is the resulting action NOT up to the application at all but
a) the application does not and shall not care about how notifications
are handled (see below)
b) the user has full control for ALL applications on how events are
handled and is NOT restricted to the mood, will and care of the
application developers.

(ftr: i've beclock flashing on various occasions, so this is not just
theoretical ;-)

> Hmm, but isn't this just showing widget popups instead of sending them
> to plasma over d-bus? I would expect something that tries galago (on
> kde/gnome) or growl (on mac) first, then falls back to the widget
> popup if everything else fails, just like knotify does.
If the application ues a passivepopup there is NOTHING you could do
about this, no matter how pointless or annoying that message is.

And once more, this is the point.
"I would expect" is a nice theory, but to push that, the application
developer is released from implementing all this by himself but just
has to say "notify_the_user()"

This is precisely why there's an abstract notification system - whether
this is done via a daemon (as by now) or plugins (as by Aaron's
proposal) is a technical detail.
Each has certtainly pros and cons but the fact that there is such system
is a giant pro that i for one wouldn't like to miss or hand out to the
"wisdom" of application developers to think of all cases.

> I definitely don't want the user to be able to disable the popup.
a) probably a design fail - sounds like you abuse a notification as
vivid UI element.
b) then just use a popup and not a notification (the kuiserver
implementation does not necessarily have to behave like plasma-desktop,
i think that ayatana thing never shows popups at all and i don't know
how eg. plasma-active behaves)
c) some users might want to enable sounds in addition (thinking of
mobile devices in your bag where you won't see the note until a sound
say "hey, do some!"

Cheers,
Thomas