@kossebau one information please, with this set of paches the svg mask is also applied and in COMPOSITING state for the panels?

In D21013#460743, @mvourlakos wrote:

@kossebau one information please, with this set of paches the svg mask is also applied and in COMPOSITING state for the panels?

Yes. As in: at least most of the time as there are still some propagation bugs in the property chain to be uncovered and fixed. At least things work properly here after a clean plasma start with a clean cache.

For compositing my reference here is the Oxygen Plasma Theme with the rounded panel corners.
One can also try my special background test theme, which points issues out clearly: https://share.kde.org/s/6zJZg8RiEReFbfA

In D21013#460745, @kossebau wrote:

In D21013#460743, @mvourlakos wrote:

@kossebau one information please, with this set of paches the svg mask is also applied and in COMPOSITING state for the panels?

Yes. As in: at least most of the time as there are still some propagation bugs in the property chain to be uncovered and fixed. At least things work properly here after a clean plasma start with a clean cache.

For compositing my reference here is the Oxygen Plasma Theme with the rounded panel corners.
One can also try my special background test theme, which points issues out clearly: https://share.kde.org/s/6zJZg8RiEReFbfA

This behavior now probably breaks a bit the Plasma PopUp placement, the code of reason may be:
https://github.com/KDE/plasma-framework/blob/master/src/plasmaquick/dialog.cpp#L902

The addition for outsideParentWindow necessity was done by me in order to find a way to place popups properly for a DOCK case (e.g. Latte).
The assumption of the referenced code is that Plasma panels under COMPOSITING mode are not using the QWindow:mask() . That assumption
now ends and that creates two questions:

1. How Plasma PopUps should be placed correctly when the window sets a mask?
2. Will there be any way for Plasma popups to be placed independently of Window geometry OR Window:mask() ? For example based on

the item that triggered the popup event

Some early approach could be: https://phabricator.kde.org/D15821 that provides a way to limit the popup based on the mask() and not just the window::geometry()

@davidedmundson had an opinion in the past that this should be fixed properly in the FUTURE by giving a way for the popup to know when it
functions in Plasma::PanelView or a Dock and as such to behave differently

Eek, sorry for breaking things. Will have some thoughts about it.
Though, hm, item->window()->mask().isNull() is really a random heuristic asking to break sooner or later, given we have seen all kind of panel/dock styles by the time :) Well, actually it was already broken before given that the Oxygen Theme is non-simple-rect and the missing proper mask was a bug.
This really needs a proper solution with well defined concepts.

In D21013#460765, @kossebau wrote:

Eek, sorry for breaking things. Will have some thoughts about it.
Though, hm, item->window()->mask().isNull() is really a random heuristic asking to break sooner or later, given we have seen all kind of panel/dock styles by the time :) Well, actually it was already broken before given that the Oxygen Theme is non-simple-rect and the missing proper mask was a bug.
This really needs a proper solution with well defined concepts.

yep, I agree...

This is why I left the assumption only in one place and I didnt merge more commits elsewhere until the situation
has a more concrete approach.... e.g. https://phabricator.kde.org/D15814

In D21013#460774, @mvourlakos wrote:

This really needs a proper solution with well defined concepts.

yep, I agree...

This is why I left the assumption only in one place and I didnt merge more commits elsewhere until the situation
has a more concrete approach.... e.g. https://phabricator.kde.org/D15814

.. until the next person (=me) runs right into this muddy waters :) Meh, I hoped I was done with any work on Plasma theming for some time, but seems I have to do some more to add to stay satisfied.

I created T10889 to track this and continue the discussion. This very patch is just a follow-up to the actual change.