Bug 399757

No, because Breeze, SierraBreeze, and BreezeEnhanced manually draw the buttons using C++. The downloadable themes use the aurorae engine which simply draws an svg. IIRC, AWC autodetects and uses those svgs, but needs to bundle svgs for breeze and breeze-dark:

https://github.com/KDE/plasma-active-window-control/tree/master/package/contents/icons

While someone could add custom svgs for BreezeEnhanged, it would not use the "hover" effect.

Is it possible with buttons written in qml?

Originally I was thinking we could maybe recreate the buttons in QML, as it's just a simple rectangle with rounded corners (to make a circle) that's centered with a simple zoom animation on the width/height.

But you know... it might be worth looking into the Window Decoration KCM. As it was converted to QML. The buttons animated there too on hover.

* https://github.com/KDE/kwin/tree/master/kcmkwin/kwindecoration
* https://github.com/KDE/kwin/blob/master/kcmkwin/kwindecoration/qml/Buttons.qml


We can get it to draw a non-animated button with:
https://gist.github.com/Zren/40f657da96e4d8a29b13d74b74e956c5

Unfortunately, it's not animated, since the KDecoration.Button is used for the "button editor".

The complete animated decoration previews could be picked apart somehow to get just the left side buttons + animated.

* https://github.com/KDE/kwin/blob/master/kcmkwin/kwindecoration/declarative-plugin/previewitem.cpp
* https://github.com/KDE/kwin/blob/master/kcmkwin/kwindecoration/declarative-plugin/previewbutton.cpp


We'd probably need to send the mouse events somehow.
* https://github.com/KDE/kwin/blob/master/kcmkwin/kwindecoration/declarative-plugin/previewitem.cpp#L361

Or could we use the code of Aurorae? 

https://github.com/KDE/kwin/blob/ea05ac380b42a0009c7a69a84ea4a5b872c3db99/plugins/kdecorations/aurorae/src/qml/DecorationButton.qml

I am in the process to play with AWC in order to support Colorize effect properly in Latte Dock. I am describing this: https://www.youtube.com/watch?v=JVbIuZp3VFQ

Latte is going to provide a new way for applets in order to be informed about a new colors palette in order to paint themselves more appropriate when the colorize effect is applied.

AWC is going to be the play thing for me... In that way the window icon is not going to be colorized monochromatic and the highlights effects will fit in without breaking the coloring experience.

After that I thought that window buttons is also of such case, the window buttons are also updating their appearance based of the current window color scheme in Breeze window theme...

I am thinking how we could do that... Adjust the kcmkwin code for AWC needs and if it is possible to pass also the color scheme value for themes that support it...

(In reply to trmdi from comment #4)
> Or could we use the code of Aurorae? 
> 
> https://github.com/KDE/kwin/blob/ea05ac380b42a0009c7a69a84ea4a5b872c3db99/
> plugins/kdecorations/aurorae/src/qml/DecorationButton.qml

if we manage to support PreviewItem and DecorationButton properly then aurorae themes will be shown correctly just like they do in kcmkwin

It will be much easier if you ask Kwin devs.

(In reply to trmdi from comment #7)
> It will be much easier if you ask Kwin devs.

I think I found it and it can be done...
https://github.com/KDE/kwin/blob/master/kcmkwin/kwindecoration/declarative-plugin/previewclient.cpp#L39

this is how default scheme is applied and this can be altered in plugin level...

1. First thing to do is to move the kcm win decoration c++ code under AWC and make it work with AWC...
2. Afterwards anything that is not needed can be removed
3. make that palette option accessible from qml just like is doing for example at: https://github.com/KDE/kwin/blob/master/kcmkwin/kwindecoration/qml/Previews.qml#L84

> It will be much easier if you ask Kwin devs.

ok achieved... ;) based on Chris Holland investigation which was fantastic!!

AWC in transparent latte panel:

Breeze: https://drive.google.com/file/d/1NTAaKe-lnMWwm0kNZcQLaDhlkRROiccn/view?usp=sharing

and we can define the colorscheme in whatever suits us that means that Latte can have always beautiful painting with it

SierraBreeze: https://drive.google.com/file/d/1wsVAU2qgo_guGR4LKCyMiUyoZMijFbct/view?usp=sharing


How this was achieved:

1. Moved the kcm decoration previews... code under AWC umbrella in its plugin...
2. I adjusted the previews... classes to not draw shadows etc.. because it isnt needed and simplifys the calculations
3. I sent through PreviewButton the mouse events to its m_button (Decoration2::DecorationButton)
4. I updated the PreviewButton to be colored when the m_button changes its flags isPressed and isHovered
5. I found a possible bug in Decoration2::DecorationButton that was ignoring some mouse events and hacked it through PreviewButton sending always mouse positions that are treated as valid from Decoration::DecorationButton

I dindnt find a way for aurorae themes to draw DecorationButton(s) but I might be missing something, I tried to set for Bridge:
plugin="org.kde.kwin.aurorae"
theme="Arc"

but even though Arc is in the system, it couldnt find it...

Brilliant! Can it also work with BreezeEnhanced? https://github.com/tsujan/BreezeEnhanced

It's theme="__aurorae__svg__Adapta"

Look at ~/.config/kwinrc

[org.kde.kdecoration2]
library=org.kde.kwin.aurorae
theme=__aurorae__svg__Adapta

(In reply to trmdi from comment #10)
> Brilliant! Can it also work with BreezeEnhanced?
> https://github.com/tsujan/BreezeEnhanced

it works with all c++ decorations including BreezeEnhanced but the decorations should take care how they will be painted when animations are disabled. Try to disable BreezeEnhanced animations from its settings and you will notice that it doesnt provide on hovering painting for minimize/mazimized/close buttons

(In reply to Chris Holland from comment #11)
> It's theme="__aurorae__svg__Adapta"
> 
> Look at ~/.config/kwinrc
> 
> [org.kde.kdecoration2]
> library=org.kde.kwin.aurorae
> theme=__aurorae__svg__Adapta

it doesnt work, you can test it with your example code...

I suppose Aurorae engine does not provide creating individual buttons and painting them individually. It supports only painting the entire decoration.

(In reply to Michail Vourlakos from comment #12)
> (In reply to trmdi from comment #10)
> > Brilliant! Can it also work with BreezeEnhanced?
> > https://github.com/tsujan/BreezeEnhanced
> 
> it works with all c++ decorations including BreezeEnhanced but the
> decorations should take care how they will be painted when animations are
> disabled. Try to disable BreezeEnhanced animations from its settings and you
> will notice that it doesnt provide on hovering painting for
> minimize/mazimized/close buttons

It means the animated effect on hovering the buttons is not possible?

(In reply to trmdi from comment #14)
> (In reply to Michail Vourlakos from comment #12)
> > (In reply to trmdi from comment #10)
> > > Brilliant! Can it also work with BreezeEnhanced?
> > > https://github.com/tsujan/BreezeEnhanced
> > 
> > it works with all c++ decorations including BreezeEnhanced but the
> > decorations should take care how they will be painted when animations are
> > disabled. Try to disable BreezeEnhanced animations from its settings and you
> > will notice that it doesnt provide on hovering painting for
> > minimize/mazimized/close buttons
> 
> It means the animated effect on hovering the buttons is not possible?

it isnt, only way for animated effects to work with individual created buttons is animations flags etc. to be officially supported from KDecoration2::DecorationButton class.

(In reply to Michail Vourlakos from comment #15)
> (In reply to trmdi from comment #14)
> > (In reply to Michail Vourlakos from comment #12)
> > > (In reply to trmdi from comment #10)
> > > > Brilliant! Can it also work with BreezeEnhanced?
> > > > https://github.com/tsujan/BreezeEnhanced
> > > 
> > > it works with all c++ decorations including BreezeEnhanced but the
> > > decorations should take care how they will be painted when animations are
> > > disabled. Try to disable BreezeEnhanced animations from its settings and you
> > > will notice that it doesnt provide on hovering painting for
> > > minimize/mazimized/close buttons
> > 
> > It means the animated effect on hovering the buttons is not possible?
> 
> it isnt, only way for animated effects to work with individual created
> buttons is animations flags etc. to be officially supported from
> KDecoration2::DecorationButton class.

Is it easily to get that support?

(In reply to trmdi from comment #16)
> (In reply to Michail Vourlakos from comment #15)
> > (In reply to trmdi from comment #14)
> > > (In reply to Michail Vourlakos from comment #12)
> > > > (In reply to trmdi from comment #10)
> > > > > Brilliant! Can it also work with BreezeEnhanced?
> > > > > https://github.com/tsujan/BreezeEnhanced
> > > > 
> 
> Is it easily to get that support?

no idea and I dont know if it would be accepted from kwin developers as accepted functionality.

But Kwinkcm preview is still able to display the animation. Can you do anything more?

(In reply to trmdi from comment #18)
> But Kwinkcm preview is still able to display the animation. Can you do
> anything more?

they are not relevant.
The kcm is painting the entire decoration and this is why animations are supported.
I opened also this one: https://phabricator.kde.org/T9899 in case any kwin developer can provide any feedback

Oops. Sorry, you're right that the individual button preview doesn't work in my first gist. I was testing with my second test that 


https://gist.github.com/Zren/ce58e1b70693e9709160110828d04c44

Breeze: https://i.imgur.com/p2EzzMM.png
Adapta: https://i.imgur.com/9Q7kPx8.png

(In reply to Chris Holland from comment #20)
> 

Chris because there is a discussion about forking AWC / maintaining etc... As I see that we both are interested to keep it alive and evolve, if the main developer does not have any issue would you like to keep it alive together?

We can pair review each other if that is the issue in order to commit through phabricator...

> 3. I sent through PreviewButton the mouse events to its m_button 

Could you share your previewbutton.cpp/.h via a gist.

I will try to fully upload it in a branch when I get back home

(In reply to Chris Holland from comment #22)
> > 3. I sent through PreviewButton the mouse events to its m_button 
> 
> Could you share your previewbutton.cpp/.h via a gist.

sorry couldnt find a better way. You can download the AWC version with: https://drive.google.com/file/d/1nNo3Mp6BeRJrrhF5KssHZM468IdrY8PP/view?usp=sharing

it draws directly two Breeze buttons in the left side of AWC

(In reply to Michail Vourlakos from comment #19)
> they are not relevant.
> The kcm is painting the entire decoration and this is why animations are
> supported.
> I opened also this one: https://phabricator.kde.org/T9899 in case any kwin
> developer can provide any feedback

Why the button size does not change on hoverEnter and hoverLeave ? 
m_animation->currentValue().toReal() inside BreezeEnhanced doesn't change when animations aren't supported ?

Or is there something prevents the button size being updated ?

(In reply to trmdi from comment #25)
> (In reply to Michail Vourlakos from comment #19)
> > they are not relevant.
> > The kcm is painting the entire decoration and this is why animations are
> > supported.
> > I opened also this one: https://phabricator.kde.org/T9899 in case any kwin
> > developer can provide any feedback
> 
> Why the button size does not change on hoverEnter and hoverLeave ? 
> m_animation->currentValue().toReal() inside BreezeEnhanced doesn't change
> when animations aren't supported ?
> 
> Or is there something prevents the button size being updated ?

on plasmoid side this isnt possible because we cant know how much we must increase or not...

this should be taken care from the theme side. The theme should use the maximum size in order to draw everything, that means sierrabreeze could do the following:

e.g. if the provided size is 50px x 50px  it could use that 50px to draw the hover state and could use a portion of them eg. 35px to draw the normal state.

It is totally theme responsibility to draw properly its states

an update: https://drive.google.com/file/d/16jUvWxFjt7GwWIF8LyM15NcPU0UQz2jH/view?usp=sharing

on purpose I am switching plugins(breeze and sierrabreeze) at every 6 hovers and
on purpose I am switching between different color schemes at every 3 hovers...

so this is totally feasible, including the color scheme change that Latte can provide per active window.

the buttons in the video are real AWC capable buttons that the user can use. 
1.Only thing is missing is the user to specify which theme prefers from the AWC settings
2. I dont quite like how the layout of AWC is produced. Is trying to do too many things e.g. buttons above the window title of menu etc...

I read somewhere that for [2] Zren is playing with it. 

Does anyone know who is responsible for AWC these days?

> Does anyone know who is responsible for AWC these days?

You, Zren, anyone else,... but not the original dev. He hasn't replied anyone on his github for a long time.

> 2. I dont quite like how the layout of AWC is produced. Is trying to do too many things e.g. buttons above the window title of menu etc...

> I read somewhere that for [2] Zren is playing with it. 

I've thought about changing the defaults to something more Ubuntu Unity like. There's now alternative widgets for displaying just the buttons + app title + global menu, so I believe this widget should focus on combining all 3 "widgets" by default in a manner similar to unity (which is probably what people are after).

https://phabricator.kde.org/D16328

(In reply to Chris Holland from comment #29)
> > 2. I dont quite like how the layout of AWC is produced. Is trying to do too many things e.g. buttons above the window title of menu etc...
> 
> > I read somewhere that for [2] Zren is playing with it. 
> 
> I've thought about changing the defaults to something more Ubuntu Unity
> like. There's now alternative widgets for displaying just the buttons + app
> title + global menu
> 

Is there an alternative widget for displaying active window buttons that I don't know of?

Is there a Kwin dev who would suggest us a way to paint only a decoration button with animation created inside its class on a Plasmoid?

and a real demonstration of this through AWC : https://www.youtube.com/watch?v=QkPv0-tfsXk

watch out the window buttons at the top right to update their color scheme properly

Nice. Are you about to release it?

(In reply to trmdi from comment #33)
> Nice. Are you about to release it?

In the following steps:
1. make independent library for decoration buttons in order for any applet to be able to draw c++ window buttons correctly -done-
2. create an independent plasmoid that will use [1] in order to provide window buttons to the user in a simple way and support Latte new painting also. - working on it - 
3. Add some functionality from AWC directly to Latte. Double click to restore/maximize. Draw active window from panel. Scroll wheel at the panel changes desktop or activity.
4. Send patches to applets including AWC to support new Latte painting. If they are not accepted I will just provide Latte versions for them with that single commit.

(In reply to Michail Vourlakos from comment #34)
> 2. create an independent plasmoid that will use [1] in order to provide
> window buttons to the user in a simple way and support Latte new painting
> also. - working on it - 
> 3. Add some functionality from AWC directly to Latte. Double click to
> restore/maximize. Draw active window from panel. Scroll wheel at the panel
> changes desktop or activity.

2. It would be great if it can wrap the official global menu into it.
3. Do you think it's possible to support this feature ?https://github.com/kotelnik/plasma-applet-active-window-control/issues/30

(In reply to trmdi from comment #35)
> (In reply to Michail Vourlakos from comment #34)

[2]. I dont think it is possible but it will be smart enough in order to hide/show itself accordingly. So it will be able to be next or before a global menu applet and the user should not notice any difference. It definitely wont be able to overlay a global menu applet.
[3]. I will need to play with it to check if the dragging can be canceled somehow, Zren has done fantastic research with it. If I have questions I will ask him

@psifidotos; 

A kwin dev has seen and answer your question in phabricator. You could discuss with him if you want.

(In reply to trmdi from comment #35)
> (In reply to Michail Vourlakos from comment #34)
> 3. Do you think it's possible to support this feature
> ?https://github.com/kotelnik/plasma-applet-active-window-control/issues/30

I just did... ;)

I manage to orchestrate this with http://doc.qt.io/qt-5/qwindow.html#setMouseGrabEnabled

open a bug report in Latte please in order to track down when this will be landed in git version.

Can PreviewButton be directly derived from KDecoration2::DecorationButton and QQuickPaintedItem ? And for class PreviewButton: Using KDecoration2::paint() like this: https://stackoverflow.com/questions/42736889/c-multiple-inheritance-same-method-names-can-i-somehow-remove-one-of-them/42737015

Because I think, currently, when PreviewButton::paint() is called, it will be redirected to m_button->paint(). It's ok for draw the button.
https://github.com/KDE/kwin/blob/master/kcmkwin/kwindecoration/declarative-plugin/previewbutton.cpp#L135

But from BreezeEnhanced, when animation is running > opacity changes > update > BreezeEnhanced::paint() is called. But this time, it don't know about the *painter -> we don't see the animation.
https://github.com/tsujan/BreezeEnhanced/blob/master/breezebutton.h#L93


So, my idea is, we make PreviewButton derived directly from KDecoration2::Decorationbutton, so its paint method will be called directly (we do not have to redirect it to m_button->paint() anymore) > it knows about the *painter to repaint when opacity changes > we will see the animation.

how will it be created? Currently Decoration creates them and returns them as DecorationButton

Isn't it created from QML file ? Because it is derived from QQuickPaintedItem. (we don't need m_button anymore)

(In reply to trmdi from comment #41)
> Isn't it created from QML file ? Because it is derived from
> QQuickPaintedItem. (we don't need m_button anymore)

because I believe you wanna play with it... :) I rushed things a bit and uploaded it at: https://github.com/psifidotos/applet-window-buttons

it is just the first commits in order to start.
1. the libappletdecoration that is provided is independent from its kcm kwin decoration counterpart
2. I have assigned minimize|close in the main.qml code by hand
3. I am using breeze in the main.qml code

of course in the future all this will be able to assigned by preferences etc... but the c++ code of libappletdecoration I think it will help you also to test things by yourself.. ;)

(In reply to trmdi from comment #41)
> Isn't it created from QML file ? Because it is derived from
> QQuickPaintedItem. (we don't need m_button anymore)

I FOUND IT!!!! :) and I AM VERY HAPPY!!! :)

this isnt a KDecoration issue!! This is Breeze faulty implementation and as such all its derivatives did not notice it!!!

you can read at: https://phabricator.kde.org/T9899 my findings!!!

With my applet afterwards animations work just fine!

Created attachment 116027 [details]
animation

OMG!!! I've just found that problem too, and was about to tell you about it.

(In reply to trmdi from comment #44)
> Created attachment 116027 [details]
> animation
> 
> OMG!!! I've just found that problem too, and was about to tell you about it.

yep!! :) do you prefer to send the patches? I was thinking to send them later today.

(In reply to trmdi from comment #44)
> Created attachment 116027 [details]
> animation
> 
> OMG!!! I've just found that problem too, and was about to tell you about it.

(In reply to Michail Vourlakos from comment #45)
> (In reply to trmdi from comment #44)
> > Created attachment 116027 [details]
> > animation
> > 
> > OMG!!! I've just found that problem too, and was about to tell you about it.
> 
> yep!! :) do you prefer to send the patches? I was thinking to send them
> later today.

No, I've just learned C++ recently. I know almost nothing. You should do this.

(In reply to trmdi from comment #46)
> (In reply to trmdi from comment #44)
> No, I've just learned C++ recently. I know almost nothing. You should do
> this.

no problem... sent and accepted...
https://phabricator.kde.org/D16596

someone should inform most of the breeze derivative creators in github in order to update their code based on https://phabricator.kde.org/D16596

can you do it please?

Sure!

Thanks everyone.
Now we have another wonderful applet for the requested feature:
http://psifidotos.blogspot.com/2018/11/window-buttons-applet-v01.html