KNotify-considerations for frameworks

[George Kiagiadakis]

On Fri, Sep 23, 2011 at 7:21 PM, Lubos Lunak <l.lunak at suse.cz> wrote:
> 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

Well, I guess the command option can always be present. I have never
seen a use for it, but I'm sure there are people that use it to do
crazy customizations. I'm all for allowing people to do such things,
provided they make sense.

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

Thinking in telepathy terms (as I am a telepathy developer), the
application that shows the approval notification (the approver) is
different than the one that handles the call and the app that handles
the call is only launched after you have approved the call from the
approver. Think that your desktop itself is the call application.
There is no separate icon for that in the system tray. So, no, you
cannot disable the popup.

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

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.

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

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

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.

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

Maybe, but they are broken... And in this case, I would expect knotify
not to require a .notifyrc file if everything is specified in the
KNotification API.

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

I am not talking about having several solutions. It will still be one
solution, but it will allow the developer to provide some context on
what this notification is about and the user interface (which will
still be one dialog in a library) will be able to reflect this
context, making things clearer for the users and allowing developers
to have guarantees about what the user can do. At least in the
telepathy approver case I mentioned above (which has been troubling me
a lot, since I am writing this thing), I definitely don't want the
user to be able to disable the popup.

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

Aaron is focusing on the technical side on how to get rid of the
daemon. I agree with him, I am just suggesting something else that
could also be done during this refactoring.

Regards,
George