Ayatana-like notifications for Plasma

[Scott Kitterman]

On Fri, 4 Sep 2009 01:39:34 +0200 Sebastian Kügler <sebas at kde.org> wrote:
>On Thursday 03 September 2009 17:40:44 Aurélien Gâteau wrote:
>> Aurélien Gâteau wrote:
>> > Sebastian Kügler wrote:
>> >> You don't need to remove the notifications from the systray by patching
>> >> it, you can just turn it off with the config option (which you're
>> >> apparently also removing). This only makes it harder to switch between
>> >> those two.
>> >
>> > I am not removing the config option: in fact I recently added a new one
>> > to toggle Ayatana notifications on or off.
>
>OK, then I didn't read the code well enough.
>
>My proposal would be to just add / remove the Ayatana applet and switch off / on the 
>native notifications. This way it could be done completely at run-time, and doesn't 
>require separate packaging -- this would make testing the Ayatana version a lot 
>easier, and make packager's lives less painful.  Note that the applet doesn't need to 
>be visible at all (make it 1x1 px transparant if you wish), or plugged into the 
>systray (which is supported since KDE 4.3).

I think this is consistent with what we discussed at UDS and I'm all for making packager's lives less painful.

>> >> Looking at the code, I see that you're basically not using the
>> >> (QGraphicsView) canvas-based system Plasma uses.
>> >
>> > True. I reused some of the code I demonstrated at UDS. Since the
>> > PassiveNotificationWidget is a standalone widget which appears over the
>> > other windows, what would using QGraphicsView bring?
>
>Deeper integration with other plasma elements, for example the slide animation in 
>Plasma::Dialog. Not sure if that's what you want, but I though I'd mention it anyway.

I think that whatever is acheivable in terms of plasma integration is important.  I view the "Ayatana mode" as a laboratory for KDE/Ayanata/Kubuntu to learn new thing to improve the user experience.  Some of the elements that are tried will work out well and be useful and some won't.  To the extent these experiments are well integrated with KDE technoloies, the more likely they are to be successful.

>> >> The Timeline stuff in there should probably use
>> >> Plasma::Animator, so the notify-osd stuff respect desktop-wide settings
>> >> for animations (you can switch them off in a central place, and have
>> >> animations in different UI elements synced with each other). Also,
>> >> hardcoding animation duration seems clunky -- again, no syncing of the
>> >> animations with other animations, no way to switch it off in a central
>> >> place.
>> >
>> > Reading the API, it seems it requires QGraphicsItem, which probably
>> > answer my previous question.
>
>Right. This will probably change when Qt kinetic arrives, hopefully in time for 4.4.
>
>> More on the subject of using QGraphicsView and Plasma::Animator: I just
>> had a look at the tooltip code, since Ayatana notifications aim at
>> looking similar to tooltips, I think it make sense to get some
>> inspiration from the code.
>
>or share it ... :)
>
>> I found out that Plasma::ToolTip inherits from QWidget, like I do and
>> use QTimeLine as well. Is it just because the code predates
>> Plasma::Animator or is it accepted architecture for new code?
>
>It's a kludge, because QWidget-based stuff isn't supported by Animator.
>
>> Still I found some interesting code in ToolTip to check global animation
>> settings and use Plasma frame margins.
>
>Yes, I think the general point here is that the Ayatana notifications have been 
>developed with GNOME in mind, which is in many ways more limited than Plasma. This 
>also means that the scope of the spec, when applied to KDE, changes. IMO, it cannot 
>be copied 1:1.

I think this is important.  Kubuntu is very much a KDE distro.  Trying to force fit Gnome into Kubuntu isn't going to get very far.

Scott K