@trmdi: Because when the user chooses Hide background... That means he never wants a background, vice versa.

I dont get it

@trmdi

+ Transparent dark/light (when the Hide background option is enabled)
+ Translucent dark/light (when the Hide background option is disabled)

transparent and translucent do not mean the same in english?

@trmdi I would propose to articulate how you image Dynamic Background options, addition/removals/changes and how they will behave between each other, what that would mean from the user point view...

1.0. Rename

I want to use these names, they are easier to understand:

+ "Force solid background for maximized or snapped windows" -> Force solid background when touching a window (Op1)
+ "Hide background for not maximized windows" -> Hide background when not touching any window (Op2)
+ "Monochrome contents when panel is transparent" -> Monochrome contents when not touching any window (Op3)

2.1. Option (Op1) does not relates to (Op2) and (Op3).

2.2. Option (Op2)

• Not used when (Op4) = Auto
• When (Op4) != Auto:
  • (Op2) = enabled -> hide background
  • (Op2) = disabled -> not hide the background

2.3. Option (Op3)

• enabled: add a dropdown (Op4)
• disabled: hide (Op4)

2.4. Option (Op4)
has these 3 options:

• Automatically: Latte decides the background color and the text color automatically, like the Elementary way, there are 4 modes (default option of the dropdown)
• Black text color
• White text color

What is needed Op4->Black/White color?

In T10274#172129, @mvourlakos wrote:

What is needed Op4->Black/White color?

For manual cases. Some wallpapers can be used with both black and white text color. It give the choice to the user.

In T10274#172130, @trmdi wrote:

In T10274#172129, @mvourlakos wrote:

What is needed Op4->Black/White color?

For manual cases. Some wallpapers can be used with both black and white text color. It give the choice to the user.

Sorry I don't fancy it

Concerning Op2, if the user does not want any background for isBusy background or if wants to alter the panel transparency in that case, he can do so by just changing the Background opacity

Sorry I don't fancy it

It's a bit subjective.

Concerning Op2, if the user does not want any background for isBusy background or if wants to alter the panel transparency in that case, he can do so by just changing the Background opacity

"Changing the background opacity" and "Hide the background" are not the same.

In T10274#172132, @trmdi wrote:

"Changing the background opacity" and "Hide the background" are not the same.

but the background toggler on/off could be used for this

@trmdi it might be better to explain the user case?

What is the use case that the user does not want a background when the desktop background isBusy?

In T10274#172135, @mvourlakos wrote:

@trmdi it might be better to explain the user case?

What is the use case that the user does not want a background when the desktop background isBusy?

For the false-positive cases.

In T10274#172134, @mvourlakos wrote:

In T10274#172132, @trmdi wrote:

"Changing the background opacity" and "Hide the background" are not the same.

but the background toggler on/off could be used for this

So we should remove (Op2) ?

In T10274#172138, @trmdi wrote:

So we should remove (Op2) ?

no, I just dont see any benefits changing the available options. It might be better going with use cases. What is the use case that the current options do not meet...

BTW I updated the options texts, your descriptions are much nicer.

In T10274#172136, @trmdi wrote:

In T10274#172135, @mvourlakos wrote:

@trmdi it might be better to explain the user case?

What is the use case that the user does not want a background when the desktop background isBusy?

For the false-positive cases.

when there are false/positive cases the background is shown, so the user can increase the background opacity in order to gain back its contrast. If there are false cases is good to test drive them as a bug.

In the case (Op4) = auto as I said above:

I mean we make (Op2) grey and don't let the user enable/disable it.
This case = the current implement when the user chooses "Hide background..." and "Monochrome..."

It just shows that the user doesn't need to care about (Op2) when (Op4) = auto.

(Op4) != auto means:

• This is a case that the user can change (Op2)

We make it grey... What do you mean? Why the user would not want it?

Is there any use case that switch off the background switch ?

In T10274#172142, @trmdi wrote:

Is there any use case that switch off the background switch ?

When the user does not want background

In T10274#172141, @mvourlakos wrote:

We make it grey... What do you mean? Why the user would not want it?

I mean this, see Spacing in this picture as an example.

Because when (Op4) = Auto, Latte chooses the background automatically.
Currently, when the user chooses "Hide background" + "Monochrome", if the desktop background is isBusy -> the text "Hide background" confuses the users. He will ask: "Why I enabled "Hide background..." but it still shows the panel background ?!?"

It shows a background because there is not enough contrast with underlying background. If the user objects to that can either change the background opacity or don't use "Monochrome..." at all...

I am not that sure that Monochrome must remain as it is because it is no monochrome any more... applets can have colors in that state

Instead of Monochrome... might be better: Increase contrast with desktop background or something similar

I am not that sure that Monochrome must remain as it is because it is no monochrome any more... applets can have colors in that state

You can change the text color without the monochrome mode?

In T10274#172183, @trmdi wrote:

I am not that sure that Monochrome must remain as it is because it is no monochrome any more... applets can have colors in that state

You can change the text color without the monochrome mode?

Yes, for those applets that support the new coloring mechanism, currently that are all three Window applets

In T10274#172181, @mvourlakos wrote:

It shows a background because there is not enough contrast with underlying background. If the user objects to that can either change the background opacity or don't use "Monochrome..." at all...

I am not that sure that Monochrome must remain as it is because it is no monochrome any more... applets can have colors in that state

I know, in that case, I didn't mean the background is unneccessary, or the opacity need to be changed.
I was talking about the text "Hide background..."., it could make him confused. So we should "grey" it.

In T10274#172186, @mvourlakos wrote:

In T10274#172183, @trmdi wrote:

I am not that sure that Monochrome must remain as it is because it is no monochrome any more... applets can have colors in that state

You can change the text color without the monochrome mode?

Yes, for those applets that support the new coloring mechanism, currently that are all three Window applets

But there are lots of applets those don't support it: Color picker, NetworkManager....
So I guess the monochrome mode is still a needed thing for the Dynamic Background feature.

As long as that does not happen always it can not be greyed out

In T10274#172189, @trmdi wrote:

In T10274#172186, @mvourlakos wrote:

In T10274#172183, @trmdi wrote:

I am not that sure that Monochrome must remain as it is because it is no monochrome any more... applets can have colors in that state

You can change the text color without the monochrome mode?

Yes, for those applets that support the new coloring mechanism, currently that are all three Window applets

But there are lots of applets those don't support it: Color picker, NetworkManager....
So I guess the monochrome mode is still a needed thing for the Dynamic Background feature.

I just propose to rename it, not removing it

In T10274#172353, @trmdi wrote:

Do you like this? Note that I've just modified the UI part to show you how checkboxes of the Background section should relate to each other.

Sorry I dont like the new terms.
In general I have not concluded about this.
What I know is why these features were implemented and why... Adding new features by providing different combinations for them I am not fond of if there are not specific user cases...

So the story about Dynamic Background.

[1] force solid background when touching a window
users proposed that it would be nice to have an option in order for their background not be always shown but only when there is a maximized window. That would give the feel that the top panel is part of the window. That made sense to me and for that reason I added it. It is the first option added concerning Dynamic Background even though at that time the Dynamic Background term was not used yet.

[5] hide background shadow for maximized windows

after [1], it was proposed that in order to keep the feel that the top panel is part of the window the panel shadows it would be nice to be hidden in that case. That also made sense to me.

[2] hide background when not touching a window

after [1] and [5] users asked for different transpareny levels between normal background mode and the dynamic background activation. That introduced option [2]. At all times options [1],[2] where giving only two transparency levels one of which should be 0% or 100% so the user with options [1] [2] and background opacity could have the following options:
(opacity 45% in used as an example)

1. 0% - 45% (option [2] && backOpacity=45%)
2. 45% - 100% (option [1] && backOpacity=45%)
3. 0% - 100% (option [1] && option [2] , then background opacity was not used)

From this point the term Dynamic Background was used because it used also by other DEs and at the same time it means something specific to the users: "a background that interacts intelligently with my system"

[3] monochrome contents when not touching a window

at some point I loved the 0% transparency and I observed that other DEs solved the contrast issue by changing the textColor based on the underlying background. I implemented that feature for v0.8 by coloring all the applets with the same and by of course losing all their coloring and this is why "monochrome" term was chosen. Even though I didnt believe that many users would use it because of its limitations at the end if was loved by the users.

[4] Paint contents based on active window scheme

by using Android I liked a lot the coloring mechanism of the top bar based on the current application used. I first observed that Nitrux had found an approach for the window titlebars and by that I introduced the new coloring mechanism that in applet can support when shown inside Latte.

**[3b] monochrome contents understand isBusy backgrounds"

backgrounds that are busy and so a monochrome textColor can not bring enough contrast is a fact so the solution Elementary proposed I like it but instead of Latte deciding the opacity of the background shown the user can choose this from the settings. With ]3b] we can have three transparency levels for the background and it is the only exception.

[4] 0% - 45% - 100% (option [1] && option [2] && option [3] && backOpacity==45% && background isBusy

Now what I have in my mind concerning [1]-[5]:

1. I know that it is a little messy but I dont want to add new possibilities yet. The idea of naming them better is nice. Probably this renaming is needed for [4] also because [4] currently needs the active window to touch the top panel, so something like: "Paint contents from active touching window scheme" or something better is needed
2. The term Dynamic Background describes in my opinion what these options are doing: "they add smartness in the background behavior"
3. In order to rename [1]-[5] then first it must be described based on its history comments why this is needed and what is its new purpose independent of other properties. Currently the purpose of [1]-[5] are very clear from development point of view.
4. I understand that for me that I was part of [1]-[5] implementation and choices about their user representation is easy to understand them. But how this is communicated better to the user I have not concluded yet.

@ngraham I would like a lot your opinion. Latte has a feature called Dynamic Background that can be used in order for the panel background to gain some smartness.

Current way of providing this to the user is the following:

you can read what each property is doing and why it was implemented at: https://phabricator.kde.org/T10274#172356

if I shouldnt have pinged you feel free to ignore that message :)

In T10274#172357, @trmdi wrote:

No, I don't want to modify/add/remove... the current features. I just want to rename/reorganize checkboxes a bit.
Why don't you like my suggestion above? I think it's easier to understand.

the texts do not represent what they are actually doing:

1. Force background when touching a window (what background ? [user can not relate what this is doing])
2. Force opaque background when touching a window (there is no such option)
3. Dynamic background when not touching any window (what will the user understand from that?)

Sorry, I didn't understand how the feature works clearly. I need to learn more about it. 😂

"Monochrome contents when not touching any window" is not always true.

• E.g.1 when you checked all options in the Dynamic background section, and maximized the window, Latte still monochromes contents -> not true
• E.g.2 when you (checked the options 1+3+5) and (unchecked 2+4) in the Dynamic background section && the Background's opacity = 80%, Latte does not "Monochrome contents when not touching any window" -> not true

So could it be renamed to "Monochrome contents when needed" ? (n1)

Edit:
Sorry, I forgot the "background isBusy" cases. (n2)

From (n1) and (n2), I suggest the new name should be: Automatically change the color when needed

In T10274#172546, @trmdi wrote:

From (n1) and (n2), I suggest the new name should be: Automatically change the color when needed

This is in the right direction, I also want to rename options [4], [5] I will think it and propose my suggestions

@trmdi I would like your opinion for, and more specifi:

1. How do you find the proposed HIG for sub-categories, e.g. Colors->Theme, Colors->From Window?

(I find it a bit more attractive but I might have wrong)

2. The new Colors section which is trying to implement your proposal + the classic Dynamic Background options?

and for Effects page also by using the new SubCategories:

1. How do you find the proposed HIG for sub-categories, e.g. Colors->Theme, Colors->From Window? and for Effects page also by using the new SubCategories:

Yes, I feel it's easy to understand too. :)

1, Should Dynamic background be merged into Background ?
Because I think the user could understand the features when he checks/unchecks the checkboxes.
The Dynamic Background title is not really necessary. That could make the user confused when there are 2 Background section.

2, Should "Hide background when not touching any window" be renamed to "Hide background when not needed" ?
And the tooltip text should be "The background will be hidden when not touching any window and the desktop wallpaper is clean enough."

• Because when "not touching any window" && "background is busy" -> background is not hidden -> the text does not describe the feature very well. While "when not needed" is right in any case.
• As for the tooltip text, you shouldn't use the "transparent" word in the tooltip text. Because "transparent" could mean opacity = 0 but the background still exists with the blurred effect, while this checkbox will hide the background completely (no blurred effect) when it works. The "hidden" word looks better. It also makes the tooltip text and the checkbox text more consistent. The user would not be confused between "transparent" and "hidden".

3, When the Background switcher is off, should all of the Dynamic Background checkboxes be disabled and ignored ?
"Force solid background when touching any window" could be renamed to "Prefer fully opaque background when touching any window"

The behavior when the background switcher is off, the background should be always hidden, even in the case "Force solid background when touching any window" is checked.

Explain: when the switcher is off, the background does not exist (be hidden) any more, so we don't have a background to be able to "remove its transparency settings"

"Prefer" instead of "Force" because it should only work when the Background switcher is on.
"Fully opaque" is eaier to understand than "solid": https://dictionary.cambridge.org/dictionary/english/opaque

@trmdi

1. Yeah it makes sense,

For [2] and [3] we will discuss it again after the new Colors options are merged and starting to work together, Currently this is a mock up. After we have some implementation to discuss and see how they work with each other we can end in new better and simpler explanations

@trmdi ok new options are in place and functional, we now need to discuss conflicts or when find bugs when activating different settings...

Dynamic Background gained one more option: "Prefer plasma opaque background for popups" so now the user has to activate this option in order for the background to become opaque for applets popups.

When Color > Theme !== Plasma and a plasmoid popup is showing, color behavior need to be changed:

Some suggestions:
1, Always use color from Plasma.
2, Use color from Plasma when Colors from Window !== None (this could be better because a plasmoid popup could be considered as a window)

In T10274#175743, @trmdi wrote:

When Color > Theme !== Plasma and a plasmoid popup is showing, color behavior need to be changed:

Some suggestions:
1, Always use color from Plasma.
2, Use color from Plasma when Colors from Window !== None (this could be better because a plasmoid popup could be considered as a window)

There is a new option for this in Dynamic Background maybe it should be the Default

In T10274#175744, @mvourlakos wrote:

There is a new option for this in Dynamic Background maybe it should be the Default

You meant "Prefer plasma opaque background for popups" ? I checked it.
Or you meant it should be changed to "Prefer plasma background and color for popups" ?

Have you enabled that option and the background is not changing to plasma one for pop ups?

In T10274#175703, @trmdi wrote:

2, Should "Hide background when not touching any window" be renamed to "Hide background when not.....

3, When the Background switcher is off, should all of the Dynamic Background checkboxes be ....

nice, I applied both [2] and [3] in last master

In T10274#175746, @mvourlakos wrote:

Have you enabled that option and the background is not changing to plasma one for pop ups?

Sure. It only makes the view's opacity = 100%, but both background color and content color do not change.

Sounds like a bug, open a bug report and a screenshot for your Dynamic background and Coloring options

In T10274#175755, @mvourlakos wrote:

Sounds like a bug, open a bug report and a screenshot for your Dynamic background and Coloring options

I think the bug could be in this: https://github.com/KDE/latte-dock/blob/90164358f6db53d87f1f42e98363b52e0b0e2cdb/containment/package/contents/ui/colorizer/Manager.qml#L50

if (root.hasExpandedApplet === true) should we return theme ?
And what will happen if the user opens a plasmoid popup then pin it, and there is another touching/activating window? What will be the return value of applyTheme ?

In T10274#175756, @trmdi wrote:

In T10274#175755, @mvourlakos wrote:

Sounds like a bug, open a bug report and a screenshot for your Dynamic background and Coloring options

I think the bug could be in this: https://github.com/KDE/latte-dock/blob/90164358f6db53d87f1f42e98363b52e0b0e2cdb/containment/package/contents/ui/colorizer/Manager.qml#L50

if (root.hasExpandedApplet === true) should we return theme ?
And what will happen if the user opens a plasmoid popup then pin it, and there is another touching/activating window? What will be the return value of applyTheme ?

it was an issue with manual Reverse theme, fixed with last commit

In T10274#175757, @mvourlakos wrote:

it was an issue with manual Reverse theme, fixed with last commit

It wasn't fixed. When root.hasExpandedApplet === flase, the latest commit didn't fix anything because of root.hasExpandedApplet === false so it will be returned before that code block can run.
https://github.com/KDE/latte-dock/blob/c211dbf0b3d0bbe99c712ca5f7e20fdd72580132/containment/package/contents/ui/colorizer/Manager.qml#L60

Btw, may the single & in that line be a typo?

In T10274#175758, @trmdi wrote:

In T10274#175757, @mvourlakos wrote:

it was an issue with manual Reverse theme, fixed with last commit

It wasn't fixed. When root.hasExpandedApplet === flase, the latest commit didn't fix anything because of root.hasExpandedApplet === false so it will be returned before that code block can run.
https://github.com/KDE/latte-dock/blob/c211dbf0b3d0bbe99c712ca5f7e20fdd72580132/containment/package/contents/ui/colorizer/Manager.qml#L60

it is in my system, at least what I found as bug.
Please open a bug report explaining all the details that you consider as bug and also screenshots of the settings in order to reproduce in my system.

In T10274#175759, @mvourlakos wrote:

Please open a bug report explaining all the details that you consider as bug and also screenshots of the settings in order to reproduce in my system.

Ok: https://bugs.kde.org/show_bug.cgi?id=404168
Btw, may the single & in that line be a typo?

Should "Prefer plasma opaque background for popups" be renamed to "Prefer Plasma theme's background and color for popups"

Because when there is a popup, it also does not use Latte's color setting.

Off-topic question: Can "View Settings" in the context menu when right clicking on a Latte View be more specific? For example, "Dock Settings" if it's a dock, "Panel Settings" if it's a panel.
Because normal users may not know what a view is.

@trmdi

"Prefer Plasma theme's background and color for popups"

that could indicate that tooltips will be colored also and that is not the case

"Dock Settings" if it's a dock, "Panel Settings" if it's a panel.

too hard probably, feel free to play of course this action is found at containmentactions

In T10274#175768, @mvourlakos wrote:

@trmdi

"Prefer Plasma theme's background and color for popups"

that could indicate that tooltips will be colored also and that is not the case

What about "Prefer Plasma theme's background and color when expanding any widget" ?

@trmdi can we close this?

Ok, it's fine now. :)