Dynamic panel coloring the mobile way for Plasma/Latte panels
Open, Needs TriagePublic

Description

Hello everyone,

I open this task in order to track the information needed and host the discussion concerning "Dynamic panel coloring for Plasma/Latte panels".

FEATURE:
Apps in mobile world can color the top panel by providing a backgroundColor and textColor specific to them when they are used. In plasma recently an approach for window titlebars was presented through MauiKit: https://plus.google.com/photos/photo/104908072417273204416/6599176399225288338 . This feature is about trying to do the same with plasma/latte panels. Latte already provides monochrome contents by indicating the desktop background and choosing between theme.backgroundColor and theme.textColor the best choice for better contrast. But the Latte approach is QML Color Overlay that doesnt distinguish contents, it paints everything. My proposal is to find a way for applets in panels to not use just theme.textColor or theme.backgroundColor but the color their containment decides

  1. Do you think that it would be nice to have such feature for Plasma Desktop?
  2. Do you know if Plasma mobile is trying to solve this somehow?

What is needed?

A. a way for apps to publish their desired background and text colors. The Mauikit way that has a color pallette file specific to that app may be a solution for this?
B. update the plasma applets to use instead of theme.textColor and theme.backgroundColor e.g. a containment.textColor/containment.backgroundColor ?
C. The containment can decided its own when to apply these colors e.g. only when an app is active and maximized and provides a relevant color set

  1. From design perspective, should the popup windows from the panel be colored accordingly ?

I could try to provide some solution concerning this if you can provide some guidelines or ideas.

mvourlakos updated the task description. (Show Details)Sep 28 2018, 8:58 PM
  1. Do you know if Plasma mobile is trying to solve this somehow?

It is currently not, I'm not sure it's desired.

What is needed?

RE: A

Kwin gets notified of the palette an app is using by filename. On X you could sniff this info, on wayland it's only sent to kwin.

A kwin script that watches for maximised windows and then broadcasts new palette names to anyone over DBus would be relatively easy and a fairly sane design.

RE: B

Putting a Plasma.colourscope on the containment should be able to do all that, though popups would be a challenge.

RE: A

A kwin script that watches for maximised windows and then broadcasts new palette names to anyone over DBus would be relatively easy and a fairly sane design.

very good idea, if kwin::client exposes it I think I could try to implement it

RE: B

Putting a Plasma.colourscope on the containment should be able to do all that

I had thought the same but it isnt straight forward.
The only approach for a Plasma.ColorScope added in a containment to be accessed from applets is if that ColorScope is published somehow to all applets and applets afterwards use it instead of using theme.backgroundColor and theme.textColor , I may have missed something though.

The other limitation of ColorScope that I dont think is ready for the job is that it can use only colors found in the current plasma theme but in different groups.
So if an app publishes a different color pallete ColorScope cant update its color values accordingly

RE: A

Kwin gets notified of the palette an app is using by filename. On X you could sniff this info, on wayland it's only sent to kwin.

A kwin script that watches for maximised windows and then broadcasts new palette names to anyone over DBus would be relatively easy and a fairly sane design.

unfortunately kwin scripting I dont think it can do the trick as color pallete isnt exposed from: https://phabricator.kde.org/source/kwin/browse/master/abstract_client.h

RE: B

Putting a Plasma.colourscope on the containment should be able to do all that, though popups would be a challenge.

You are right for ColorScope concerning the colour inheritance I used a PlasmaCore.ColorScope in containment qml view code and tested with some applets to use PlasmaCore.ColorScope.textColor and backgroundColor
it worked just fine!!! :)

Only thing remains is :

  1. ColorScope to support user specified color pallette
  2. All plasma applets to move from theme.textColor/backgroundColor etc... to PlasmaCore.ColorScope.textColor/backgroundColor :)

I can sent patches for both if you think they could be accepted!!! :)

@davidedmundson a small demonstration based on the current infrastructure...

https://youtu.be/JVbIuZp3VFQ

of course it is still missing a way for the ColorScope to set a user palette D15389 and for plasma applets to be updated and Plasma::Svg if there was a way to support this...

and this is its updated version.

Because ColorScope is not ready yet, I provided a Latte way to demonstrate what I had in my mind....
https://www.youtube.com/watch?v=8hcfpWNLL2M

@mart can you please provide your opinion in this?

Latte has reached a state that can do the following with color schemes fromm windows: https://www.youtube.com/watch?v=8hcfpWNLL2M , observe please the automatic colorizing at top panel based on active/touching window color scheme.

The Latte solution of course it is not as clean and generic as I would like it to be.

Current Limitations:

  1. applets should support the Latte solution and it isnt plasma generic
  2. icons e.g. in the systray can not be selectable been painted

observing the Kirigami code, I noticed the color option for Kirigami.DesktopButton which in my understanding for totally monochromatic icons it can provide any desired color for that buttons.

As in the near future all Plasma applets/panel code etc will move to Kirigami, Would you consider a more generic approach based on colorScheme files?

What I have in my mind is the following:

Plasma framework currently supports such implementation for "Current Color Scheme". The Plasma cache for this color scheme creates a reference of icons/colors and all of them are provided globally without any duplicating effort.

How about the following:

We can add a colorScheme: "filepath" for DesktopIcon for example. the DesktopIcon is accessing the Svg and the Svg looks in the cache for a reference for that specific colorscheme path. In that way any icon could be painted correctly and at the same time with any desired colorscheme.

Maybe a value for ColorScope might also be needed e.g. Kirigami.ColorScope.colorScheme