Ayatana-like notifications for Plasma

[Aurélien Gâteau]

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.

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

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

> The bordering and spacing is also hard-coded, so it 
> won't be the same as other elements in the desktop. Consistency across the desktop is 
> IMO pretty important here.

I picked the notify-osd defaults here. Is there a Plasma equivalent of 
calls like KDialog::marginHint(), KDialog::spacingHint(), or would you 
expect me to use these?

> Adding a small applet (small as in visible size) and have that let handle the 
> notification visualization using the QGraphics* and Plasma classes that are supposed 
> to handle these things smoothly. That way you don't need to cripple existing code, 
> and get better integration for free.

I don't think adding another applet to handle notifications make sense. 
How would you explain this to the user?

> On top of that, you just flip one switch in the 
> config and add a custom notification applet, no need to replace complete packages. 

In the implementation I wrote you just toggle a checkbox.

> Another pretty fundamental thing is the location of the popup. Putting it top right 
> is a bit of a strange decision -- if understandable for those running GNOME (GNOME 
> has more of those notification / systray type stuff in the top panel, KDE doesn't). 
> Something to take up with the Ayatana team I guess. This way, it seems to be out of 
> place to me.

We could make this configurable I think. Even notify-osd is getting 
configurable bubble placement these days.

> BTW, what do you do with apps that have actions on their notifications? I haven't 
> read the code closely enough to find out. I understand that passive notifications go 
> top-right, the rest bottom left? How does this work with the removed extender stuff 
> in your patch? Does this keep the active ones fully intact?

The patch you read kept active notifications intact, but since then we 
discussed this subject with Celeste and she advised against having two 
places and two different representations for notifications. Instead she 
suggested to turn all notifications into passive notifications *if and 
only if* Ayatana notifications are enabled.

Aurelien