KNotify-considerations for frameworks

[George Kiagiadakis]

On Fri, Sep 23, 2011 at 2:01 AM, Sune Vuorela <nospam at vuorela.dk> wrote:
> On 2011-09-22, Sune Vuorela <nospam at vuorela.dk> wrote:
>> Currently, it is a quite complex framework that is hard to debug for the users
>> of knotify (the application developers). It seems a bit overengineered,
>> at least compared to how many of the features that is normally used.
>>
>> the full knotify stack can notify users in I think at least 5 different
>> ways:
>> Popup
>> Sound
>> Run-a-command
>> kttsd
>> nothing

I agree that this is indeed a bit overengineered and complex. I have
found myself a lot of times cursing it for requiring me to create a
configuration file just to show a simple popup, plus not respecting
any of the options on the KNotification object (as everything is
re-read from the configuration file anyway).

>> What I would like to do is the following:
>>
>> Create a handful of classes, either in a separate library or in a
>> fitting library, basically giving a public api to skip over the
>> configuration bits and knotify bits for the Popup case. There is code
>> available for several platforms already in the knotify code.
>
> Consider doing some classes for Phonon to do audio notifications for
> those who needs that or alternatively get a cross desktop audio
> notification dbus spec, just like the galago spec and get the workspaces
> to implement it. (Issue here might be that Gnome has chosen that one
> need to link libcanberra for audio notifications)
>
>> Make teh current knotify stack use the above code for popups and move it
>> either to kde4support or to the high level platform integration bits.
>> Depending on where it goes, I would like to also fold in the knotify
>> daemon into the KNotification classes, as a daemon to - mostly rewrite
>> dbus messages - seems a bit extreme[x].
>>
>>
>> Comments, requests for more details and questions are most welcome

I agree with parts of this plan, but not all of them. I think we need
to study more the use cases. Let's consider a few examples.

1) Your IM client informs you of a new message. You probably want a
popup, or a sound, or both, and possibly kttsd speaking the message
(for people with disabilities), and of course you want all of this
configurable. I think this is the best example use case of the current
KNotify stack. The full capabilities of knotify should be available in
this case, there is no point in having app authors reimplement this
themselves.

2) Your music player informs you of the next song that is going to be
played. You most likely want a popup here. Anything else would be
annoying. Plus, there is no good reason for having this configurable
from the knotify settings dialog, since it can just be a checkbox in
the music player (which it already is in amarok for example).

3) Your voip software informs you of an incoming call. You definitely
want a persistent popup with accept/reject buttons and you may also
want a persistent ringing sound. Disabling the popup should not be
allowed, or else users will not be able to handle the call, so the
only thing that you can have configurable is the sound.

4) Your window manager wants to play sounds for window events like
minimize, maximize, close, etc... There is absolutely no reason to
allow the user configuring popups for these notifications, as well as
anything else. Just sounds are enough.

So, what I think that should happen is this:

Create something in tier1 (or tier2 if needed) that allows people to
just show popups, then something else to just play sound
notifications, etc... These will be useful for non-KDE applications as
well as for applications that want to handle configuration on their
own (examples 2 and maybe 3 above). It is a pitty, for example, that
at the moment there is no Qt library that can directly show popups
using the galago spec and Qt software authors have to use gnome's
libnotify or dbus directly for this purpose.

Then, in the platform integration libraries or maybe tier2/3 solution
libraries (not kde4support, as it is not something we are
deprecating), place an equivalent of the current knotify stack, but
perhaps simplify it a bit, as you said. The daemon is not necessarily
needed (except for the sound perhaps), a lot of the options on the
KNotification object are also not needed (they are read from the
config file), QWidget dependency is also not needed, etc...

In addition, I think that the knotify stack should be adjusted to
target more specific use cases rather than being a generic framework
that can do anything. It should allow to specify the kind of
notification that this is meant to be (popup or sound or both or ...)
and represent this in the configuration UI. So for example KWin and
certain games that use knotify for sounds should be in a category with
sounds and the users should not be allowed to configure popups for
these notifications (as it makes no sense) and similarly for other
cases. Try to study a bit what use cases we have in KDE, put them in
groups and target each group separately. This will simplify things,
both for developers and users. The current solution of having one
system that can do everything and people using it for  completely
different use cases creates this feel of complexity that we have.

Just my 2 cents...

Regards,
George