(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);

That is not enough, look at this:

CtrlLib/ArrayCtrl.h:686

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

    EvenRowColor();

   push ink = SColorText;
   push paper = Blend(SColorMark, SColorPaper, 220)
   push this
   call ArrayCtrl::EvenRowColor

mirek wrote on Sun, 06 October 2024 15:37

That is not enough, look at this:

CtrlLib/ArrayCtrl.h:686

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

Please educate me if I am wrong.

What are SColorMark, SColorPaper, SColorText? Are they some Color variable in ArrayCtrl's Chameleon Style?

When a user code called

    EvenRowColor();

Something like this happen (conceptually)

   push ink = SColorText;
   push paper = Blend(SColorMark, SColorPaper, 220)
   push this
   call ArrayCtrl::EvenRowColor

If SColorText, SColorMark, SColorPaper are all refreshed after the theme change, EvenColor should receive correct color parameters.

So if instead of store a copy of SColorxxx(), let it store a reference/pointer of SColorxxx() instead. And all SColorXXX() should return Color& instead of Color.

Will this be adequate?

Hi,

Sorry to interfere here, but I would not mind having both theme dependent SColors and "SkinChanged" virtual method called on Ctrls when system theme changes. When the theme changes, everything obviously needs to be Refresh()ed, which could be the default behavior of "SkinChanged". But that is not sufficient, as in some cases content is cached in pre-rendered images which are not aware of the changed theme. Therefore, "SkinChanged" is needed to re-render everything followed by Refresh().

Is there a way to run a test on this? Maybe a branch for testing the idea?

Best regards,

Tom

Do you mean that we can have SColorPaper,SColorMark theme-sensitive, but there is no guarantee Blend(SColorPaper, SColorMark, 220) will make any sense in all possible themes we may throw at it?

Not yet. After 2024 release, I can add the changes to the master - however for forseeable future, we will need "allow theme changes" flag/function call.

I mean that Blend(SColorPaper, SColorMark, 220) has to be evaluated at some point. From developer perspective, the most logical point is when he calls Blend. It this was supposed to work without SkinChanged, we would need to do something like changing all colors stored in widgets to functions. I do not think that is a good idea...

Mirek

//header
struct SysColors
{
   Color paper;
   Color ink;
   Color mark;
   Color highlight;
   ...
   void RefreshColors();

   ...

   static SysColors scs;

private:
   SysColors(){ RefreshColors(); }
};
Color& SColorPaper = SysColors::scs.paper;
Color& SColorMark  = SysColors::scs.mark;
//cpp
SysColors SysColors::scs;

Blend(SColorPaper, SColorMark, 220)

mirek wrote on Mon, 07 October 2024 10:40

Not yet. After 2024 release, I can add the changes to the master - however for forseeable future, we will need "allow theme changes" flag/function call.

Thanks! Looking forward to both of these events!

Best regards,

Tom

I am mostly on DarkStyle, means I don't need to switch back and forth. It's a matter of u++ user experience.

mirek wrote on Mon, 07 October 2024 03:43

I mean that Blend(SColorPaper, SColorMark, 220) has to be evaluated at some point. From developer perspective, the most logical point is when he calls Blend. It this was supposed to work without SkinChanged, we would need to do something like changing all colors stored in widgets to functions. I do not think that is a good idea...

Mirek

//header
struct SysColors
{
   Color paper;
   Color ink;
   Color mark;
   Color highlight;
   ...
   void RefreshColors();

   ...

   static SysColors scs;

private:
   SysColors(){ RefreshColors(); }
};
Color& SColorPaper = SysColors::scs.paper;
Color& SColorMark  = SysColors::scs.mark;
//cpp
SysColors SysColors::scs;

Then

Blend(SColorPaper, SColorMark, 220)

will be evaluated everytime with refreshed System Colors.