(Note: I am doing all this because previous algorithm blue undo arrow icon was basically translated to white... so trying something that leaves it blue).

Mirek

Hi Mirek,

Very, very nice! After tuning for a good while, I ended up with 0.24, 0.7, 0.16 ... but then I looked at the old code and there was within a comment 0.21, 0.72, 0.07 for physiologically correct values. I guess they are even better with this new algorithm.

Hi Mirek,

These two functions can be useful tools when working with colors, so please feel free to merge them in Color.h / Color.cpp if you like:

// Formula from https://www.w3.org/TR/2008/REC-WCAG20-20081211/#relativeluminancedef

double RelativeLuminance(Color color) {
	auto comp = [&] (double c){
		c /= 255;
		return (c <= 0.03928) ? c / 12.92 : pow((c + 0.055) / 1.055, 2.4);
	};
	return comp(color.GetR()) * 0.2126 + comp(color.GetG()) * 0.7152 + comp(color.GetB()) * 0.0722;
}

// Formula from https://www.w3.org/TR/2008/REC-WCAG20-20081211/#contrast-ratiodef

double ContrastRatio(Color c1, Color c2) {
	double rl1 = RelativeLuminance(c1);
	double rl2 = RelativeLuminance(c2);
	return (max(rl1, rl2) + 0.05) / (min(rl1, rl2) + 0.05);
}

Best regards,

Tom

Now that DarkTheme() 'color inversion' works so great, maybe a slight tuning of default TheIDE text colors (along the lines laid out in material.io Dark theme documentation) is in place. I'm thinking about:

Tom1 wrote on Sat, 14 September 2024 22:32

Now that DarkTheme() 'color inversion' works so great, maybe a slight tuning of default TheIDE text colors (along the lines laid out in material.io Dark theme documentation) is in place. I'm thinking about:

Default scheme should always be "host". However, I can add alternative dark theme, if you supply one. It is quite easy, check

CtrlLib/Ch.cpp:716

Mirek

It would be nice to have theme loading clearly split to two parts:

1. Load system colors (custom or platform) and store with "SColor*_Write();" functions like before.
2. Load shapes/styles from host like in ChHostSkin() (or load custom shapes/styles), and combine with preloaded SColor*() colors for a complete theme.

Tom1 wrote on Tue, 17 September 2024 20:31

It would be nice to have theme loading clearly split to two parts:

1. Load system colors (custom or platform) and store with "SColor*_Write();" functions like before.
2. Load shapes/styles from host like in ChHostSkin() (or load custom shapes/styles), and combine with preloaded SColor*() colors for a complete theme.

You cannot load just shapes. All 3 hosts we use paint the whole widget (think images of widgets).

Mirek

mirek wrote on Wed, 18 September 2024 00:45

Tom1 wrote on Tue, 17 September 2024 20:31

It would be nice to have theme loading clearly split to two parts:

1. Load system colors (custom or platform) and store with "SColor*_Write();" functions like before.
2. Load shapes/styles from host like in ChHostSkin() (or load custom shapes/styles), and combine with preloaded SColor*() colors for a complete theme.

You cannot load just shapes. All 3 hosts we use paint the whole widget (think images of widgets).

Mirek

>
OK, I see. So, basically we're stuck with the colors given by host, right? I mean for buttons, scroll bars and more...

DarkTheme in windows is currently sort of hack - we apply DarkTheme on light theme widgets (because that is what API we currently use is returning).

Mirek

If upp can listen to the event and request all Ctrl to Refresh (hierachically) themselves, and all SColorXXX returns a reference (to a static variable who has application-long life time which will by updated by Upp at theme-changes), a upp application can behave more similar to a native gnome/x11 application.

However, all user programs alos need to change accordingly to use Color& instead of Color to store SColorXXXs that they use in their own chameleon style. But this won't break their programs catastrophically even if they don't: any part that they call SColorXXX on the site will be reflectly after first Refresh, while the part they stored a copy of SColorXXX, in, for example, a Chameleon style, will only be corrected after a restart.

The problem with switching the theme is actually a problem of all those stored colors in all widgets and data. E.g. what to do with AttrText that has some dark adjusted ink stored in it.

U++ can actually switch the theme with immediate response (just check upptst::ChStyle, it does just that - but notice that background in example ArrayCtrl does not change), the reson for restart is actually to make developer's live easier.

But OK, I can add "SkinChanged" virtual method and leave the immense work of reskining color in developer maybe...

Mirek

That is not enough, look at this:

CtrlLib/ArrayCtrl.h:686

ArrayCtrl& EvenRowColor(Color paper = Blend(SColorMark, SColorPaper, 220), Color ink = SColorText);