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.