Reduce code/effort duplication around color scheme support
Open, Needs TriagePublic

Description

While adding support for active, link, visited, negative, neutral and positive background roles, I noticed that there was an awful lot of tedious copying/pasting and occasionally slight modification involved in that work. That was only with Kirigami and qqc2-desktop-style. Now I'm working on plasma-framework, which has more of the same. I believe KIconThemes is still missing a lot of color scheme colors because there are lots of CSS color scheme classes that work in plasmashell, but not in applications.

Surely there's a better way to handle all of this with minimal duplicated effort while still providing an easy way to use color scheme colors?

QPalette has a color(ColorGroup, ColorRole) function that is easy to use and easy to recreate. Maybe we'd have to copy/paste the ColorSet, ForegroundRole, BackgroundRole and DecorationRole enums from KColorScheme for tier 1 frameworks (or maybe use git submodules?), but that's a lot easier than making tons of functions and function definitions that are only slightly different from each other and just return a single color.

I realize we'd still have to maintain compatibility with existing code, but maybe we can introduce color(ColorSet, *Role) functions and deprecate the old, tedious to make methods for using color scheme colors?

I also realize that framework design is not my area of expertise and I'm interested in what others have to say.

ndavis created this task.Jan 20 2020, 10:14 PM
ndavis added a project: KF6.
ndavis updated the task description. (Show Details)Jan 20 2020, 11:20 PM
ognarb added a subscriber: ognarb.Jan 21 2020, 12:11 AM

QML can use C++ functions right? Would we still need to make property bindings for all the colors if we had color() functions?

QML can use C++ functions right? Would we still need to make property bindings for all the colors if we had color() functions?

C++ functions can be exposed to QML.

However:

color: myObject.color(fooBar);

has one behaviour big behavioural difference to

color: myObject.fooBarColor;

The former won't know when to update, the latter can.

As for the duplication a lot is simply down to layering and dependency issues of the time. If we can move this, then we're sorted.
Extending QPalette would be the ideal solution to that.

The former won't know when to update, the latter can.

So we'll need to make property bindings anyway? Or maybe we can use arrays instead of writing 108 individual variables?

As for the duplication a lot is simply down to layering and dependency issues of the time. If we can move this, then we're sorted.
Extending QPalette would be the ideal solution to that.

I'm a little confused. Are you saying we should contribute new ColorRoles to QPalette and deprecate KColorScheme?