KNotify-considerations for frameworks

[Lubos Lunak]

On Friday 23 of September 2011, George Kiagiadakis wrote:
> 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.
...
> 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).

 So I cannot have e.g. a custom command that shows the song name in an OSD or 
whatever form I'd want

> 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.

 or to disable the popup, leave just the sound and accept the call simply in 
the app itself

> 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.

 or have a popup saying 'window XYZ demands attention'

 or have a KWin compositing effect, or whatever else that I haven't come up 
with but that doesn't mean nobody else can?

> So, what I think that should happen is this:
>
> Create something in tier1 (or tier2 if needed) that allows people to
> just show popups,

 Such a thing has been there since ages, KPassivePopup, and I've always hated 
it when somebody used it directly instead of KNotification.

> a lot of the options on the KNotification object are also not needed (they
> are read from the config file)

 That's right, but I'd expect they were added mostly for people with this "I 
want only this exact event to happen" line of thinking that you show.

> 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.

 Which part exactly would be simplified? Creating several specialized 
solutions instead of one, having developers to think about what they should 
use instead of notify("eventname"), or the user interface where the apps will 
need their own GUI and will not let users change half of the things?

 If there are perceived problems with KNotification, Aaron's mail has a much 
better approach to handling them.

-- 
 Lubos Lunak
 l.lunak at suse.cz