adding lxqt color pallete's

[ringo32]

More color options for standard lxqt ?

[tsujan]

I think it's a good idea to add some LXQt palettes to lxqt-themes. We just need to agree on the colors later.

[ringo32]

Atleast general colors 😅

[stefonarch]

Some points I see:

• Adwaita and arc are quite the same as "reset". But as "reset" isn't clear anymore one "default light" palette is ok IMHO
• link colors in some dark themes are too dark/hardly readable (check in "Help > Information" in PCmanFm-qt or "lxqt-about")
• In lxqt-about with arc-darker text isn't readable (white-on-white), but this looks like a bug there @tsujan ?

[tsujan]

In lxqt-about with arc-darker text isn't readable (white-on-white), but this looks like a bug there @tsujan ?

No, lxqt-about is OK. Theoretically, arc-darker is OK too but, in practice, it isn't.

As I've emphasized in lxqt/lxqt#2073 (comment), the window and view colors (and so, the view text and window text colors) should NOT have a high contrast with each other. arc-darker contradicts this and causes troubles.

The root of problem is in Qt. Qt allows a high contrast but assumes there's none. So, we should avoid such palettes.

[tsujan]

Please also check if another palette has that "problem".

[stefonarch]

Please also check if another palette has that "problem".

I went trough all already and found the above mentioned things. Afaik arc-dark issue is seen only in lxqt-about, but didn't check every application, pcmanfm-qt was ok.

[tsujan]

Afaik arc-dark issue is seen only in lxqt-about, but didn't check every application, pcmanfm-qt was ok.

Qt sometimes contradicts itself, to say nothing of so many Qt and KDE apps that contradict Qt. Of course, the bugs aren't ours but we can't say to every user, "Report it to...".

[stefonarch]

I see it's again oxygen's fault with arc-darker... those widget styles are like the WMs - no one is perfect.

[tsujan]

Right, no one is perfect.

But there are some basic problems with a high contrast between view and window colors. For example, in the implementation of symbolic SVG icons, it's assumed that those colors do not have a high contrast with each other, so that if they do, you might see white symbolic icons on light backgrounds or black symbolic icons on dark backgrounds.

There are other problems too. I'm not saying that Qt should have made that high contrast impossible but it could have warned the user in its documentation.

The same is true about a high contrast between button and window colors. Qt allows it but some apps have problems with it. Since there were too many apps of this kind, I didn't add button and button text colors to the palette implementation. They could be added later if we feel that we could tolerate the future reports about unreadable button texts ;)

[tsujan]

BTW, GNOME has "solved" such problems by making custom styles harder and harder to create. It has even announced (I don't remember where) that any GTK style other than the default one may show problems, implying that it has no plan to fix those problems in its apps.

Of course, we don't "solve" problems in that way but need to be a little cautious because of the current situation.

[stefonarch]

Interesting, didn't know that there are more colors. But yes, less is probably more then.
I remember I had to remove ~/.kde to come back to an usable desktop in my KDE times (is was about then I had razor-qt as fallback)

[tsujan]

Interesting, didn't know that there are more colors.

To be thorough, this is the list of colors, each of which can have 3 variants, namely, active, inactive and disabled:

Window
WindowText
Base
AlternateBase
Text
ToolTipBase
ToolTipText
PlaceholderText
Button
ButtonText
Highlight
HighlightedText
Link
LinkVisited
BrightText
Light
Midlight
Dark
Mid
Shadow

So, there can be about 60 colors (or, if we consider the fact that tooltips can't be inactive or disabled, a little less than 60).