Create Task
Maniphest T9899

Support Decoration2::DecorationButton animations in single created buttons
Closed, ResolvedPublic
Actions

Description

Hello everyone,

we are messing around with Decoration::DecorationButton(s) for https://bugs.kde.org/show_bug.cgi?id=399757
the goal is to provide the window buttons painting in a plasmoid.

I used the kcmkwin decoration code as an example for this.

[1] In my undestanding single created DecorationButtons do not support animations, they support only painting themselves through paint function, is that correct?
[2] Animations shown in the kcm are drawn because this is provided by the Decoration itself painting, is that correct?

A:[1] if this is true, is it possible to support the animations signaling through DecorationButton(s)?
A:[2] if this is true, it doesnt help drawing the entire decoration because it draws also the background that we dont need it and we also cant get a signal for which button was pressed.

With the current infrastructure we have reached at this point:
Breeze: https://drive.google.com/file/d/1NTAaKe-lnMWwm0kNZcQLaDhlkRROiccn/view?usp=sharing
SierraBreeze: https://drive.google.com/file/d/1wsVAU2qgo_guGR4LKCyMiUyoZMijFbct/view?usp=sharing

these are DecorationsButton(s) painted in a transparent latte panel

Related Objects

trmdi added a subscriber: trmdi.Oct 20 2018, 9:51 AM
graesslin added a comment.Oct 27 2018, 4:44 PM

KDecoration does not paint itself. The painting is completely controlled from outside, it's optimized for the use in KWin in the composited case. You need to trigger the painting yourself.

mvourlakos added a comment.Oct 27 2018, 4:54 PM
In T9899#165340, @graesslin wrote:

KDecoration does not paint itself. The painting is completely controlled from outside, it's optimized for the use in KWin in the composited case. You need to trigger the painting yourself.

I tried to trigger the painting with DecorationButton::paint() at hoverEnter and hoverLeave events and it draws correctly the states, but with no animation at all do I miss something?

graesslin added a comment.Oct 28 2018, 8:44 AM
In T9899#165341, @mvourlakos wrote:
In T9899#165340, @graesslin wrote:

KDecoration does not paint itself. The painting is completely controlled from outside, it's optimized for the use in KWin in the composited case. You need to trigger the painting yourself.

I tried to trigger the painting with DecorationButton::paint() at hoverEnter and hoverLeave events and it draws correctly the states, but with no animation at all do I miss something?

The animation is completely inside the decoration plugin (e.g. breeze). Due to that it's not possible to tell you whether you miss something. The complete API is just not meant for the usecase you have.

mvourlakos added a comment.Oct 28 2018, 9:07 AM
In T9899#165371, @graesslin wrote:
In T9899#165341, @mvourlakos wrote:
In T9899#165340, @graesslin wrote:

The animation is completely inside the decoration plugin (e.g. breeze). Due to that it's not possible to tell you whether you miss something. The complete API is just not meant for the usecase you have.

I see, Martin in case I upload the library that trys to support drawing the window buttons for applets will you be able to take a look?

The library is totally based at your kwinkcm/kdecoration that I think most of it is your implementation: https://github.com/KDE/kwin/tree/master/kcmkwin/kwindecoration
the idea was that as long the kcm can draw the window buttons correctly then an applet could also. Based on that I used the PreviewButton class and not the PreviewItem.

The PreviewItem draws the entire decoration with animations enabled (but drawing the entire decoration is not relevant to this use case)
The PreviewButton draws the buttons correctly for DecorationButton based engines but with no animations at all.

A dev said that PreviewButton(s) are used in the window buttons editor so I dont know if the animations were not needed or that Decoration2::DecorationButton
can not handle the case.

mvourlakos added a comment.Nov 1 2018, 4:03 PM

@graesslin I found it!!

Can you please confirm it from c++ point of view?

KDecoration is just fine. the issue is with the engines implementation Breeze etc... I suppose that all derivatives of Breeze used the same code and because there wasnt an applet to test things this is why noone noticed it...

I used BreezeEnhanced to confirm it, let's take Breeze code to see what is happening:

at line: https://github.com/KDE/breeze/blob/master/kdecoration/breezebutton.cpp#L64
we can notice the creator which is called externally not from decoration. but that creator is calling DecorationButton and not Button!!!
So all the initialization of animations is not triggered. I used instead the following, and all the animations worked just fine afterwards for the use case:

Button::Button(QObject *parent, const QVariantList &args)
    : Button(args.at(0).value<DecorationButtonType>(), args.at(1).value<Decoration*>(), parent)
{
    m_flag = FlagStandalone;
}
zzag added a subscriber: zzag.Nov 1 2018, 4:13 PM
In T9899#165947, @mvourlakos wrote:

we can notice the creator which is called externally not from decoration. but that creator is calling DecorationButton and not Button!!!

Can you please submit a patch that fixes this issue? (also, if you have time, can you please submit a patch against oxygen as well?)

mvourlakos added a comment.Nov 1 2018, 4:14 PM
In T9899#165949, @zzag wrote:
In T9899#165947, @mvourlakos wrote:

we can notice the creator which is called externally not from decoration. but that creator is calling DecorationButton and not Button!!!

Can you please submit a patch that fixes this issue? (also, if you have time, can you please submit a patch against oxygen as well?)

Definitely!!! :)
I will send both for Breeze and Oxygen in the next days!

mvourlakos closed this task as Resolved.Dec 8 2018, 11:14 PM

All this has been accomplished and presented through:

https://store.kde.org/p/1272871
https://github.com/psifidotos/applet-window-buttons