Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ Library support » Look and Chameleon Technology » Dark theme issues
Re: U++ 2019.1.rc4 released [message #51632 is a reply to message #51626] Mon, 22 April 2019 12:47 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1391
Registered: September 2007
Senior Contributor
mirek wrote on Mon, 22 April 2019 11:33
https://www.ultimatepp.org/forums/index.php?t=msg&th=106 59&start=0&

It is certainly a step in the right direction. Got the latest nightly.

I still have eye pain from staring at the TheIDE for the last few days, so I'll get back to you in a couple of days.

But I need a break first. I'm going into the code and turning off dark mode so I can work in piece for a bit.

Which brings me to: we need and option to disable dark mode in TheIDE, even if a restart is needed.
Re: U++ 2019.1.rc4 released [message #51634 is a reply to message #51632] Mon, 22 April 2019 16:09 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1391
Registered: September 2007
Senior Contributor
Yeah I'm having a real hard time figuring out what is actually taken from Windows and what is U++ convention when it comes to Chameleon, especially for dark mode.

And probably things are different on Gtk and Mac...
Re: U++ 2019.1.rc4 released [message #51636 is a reply to message #51634] Mon, 22 April 2019 20:03 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12017
Registered: November 2005
Ultimate Member
cbpporter wrote on Mon, 22 April 2019 16:09
Yeah I'm having a real hard time figuring out what is actually taken from Windows and what is U++ convention when it comes to Chameleon, especially for dark mode.

And probably things are different on Gtk and Mac...


Exactly.
Re: U++ 2019.1.rc4 released [message #51640 is a reply to message #51636] Tue, 23 April 2019 08:58 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1391
Registered: September 2007
Senior Contributor
mirek wrote on Mon, 22 April 2019 21:03
cbpporter wrote on Mon, 22 April 2019 16:09
Yeah I'm having a real hard time figuring out what is actually taken from Windows and what is U++ convention when it comes to Chameleon, especially for dark mode.

And probably things are different on Gtk and Mac...


Exactly.

Well I'm having a hard time figuring it out but you know the system. Smile

Speaking off, I implemented live skin switching. Pretty hard to do because a lot of controls cache several values and there is no universal OnThemeChanged virtual method with deep GUI traversal.

And I'm also having this problem: I'm in dark mode, I switch to light mode once, icons are still dark. I switch a second time to (the same) light mode, icons are light. Is this the dark mode icon cacher? If yes can we force an invalidate in it with some API?

Anyway, here is an early demo, compiled for Win because I had to do a few small changes to U++:
https://drive.google.com/open?id=18sCUaufbYdv1XBS8W21mcc61uL qK-YKL

The "skin" buttons on the toolbar change the skin.

[Updated on: Tue, 23 April 2019 08:59]

Report message to a moderator

Re: U++ 2019.1.rc4 released [message #51641 is a reply to message #51640] Tue, 23 April 2019 09:04 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12017
Registered: November 2005
Ultimate Member
cbpporter wrote on Tue, 23 April 2019 08:58
mirek wrote on Mon, 22 April 2019 21:03
cbpporter wrote on Mon, 22 April 2019 16:09
Yeah I'm having a real hard time figuring out what is actually taken from Windows and what is U++ convention when it comes to Chameleon, especially for dark mode.

And probably things are different on Gtk and Mac...


Exactly.

Well I'm having a hard time figuring it out but you know the system. Smile

Speaking off, I implemented live skin switching. Pretty hard to do because a lot of controls cache several values


That is exactly the reason why we support setting skin on startup.

See, I guess there is a certain mismatch of expectations. For me and for U++ users I care about, skinning is not that important. I just want the app look as much integrated into host as possible, do not care much above that. And most users do not switch themes 3 times per hour.

Quote:

And I'm also having this problem: I'm in dark mode, I switch to light mode once, icons are still dark. I switch a second time to (the same) light mode, icons are light. Is this the dark mode icon cacher? If yes can we force an invalidate in it with some API?


Fixable, just forgot to fix it.

Mirek
Re: U++ 2019.1.rc4 released [message #51647 is a reply to message #51641] Tue, 23 April 2019 09:55 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1391
Registered: September 2007
Senior Contributor
mirek wrote on Tue, 23 April 2019 10:04

That is exactly the reason why we support setting skin on startup.

See, I guess there is a certain mismatch of expectations. For me and for U++ users I care about, skinning is not that important. I just want the app look as much integrated into host as possible, do not care much above that. And most users do not switch themes 3 times per hour.


Yeah, but that only works if you expect nobody to fine tune the skin. If you are fine with the high contrast eye-strain default skin.

You could fine tune it before TopWindow starts, but TheIDE for example, sets the skin after loading the settings, so all changes done before the main window is created are lost. So maybe if proper live skinning won't be supported, TheIDE should be fixed so you can:

#ifdef flagMAIN
GUI_APP_MAIN
#else
void AppMain___()
#endif
{
//	Ctrl::ShowRepaint(50);

	Logi() << UPP_FUNCTION_NAME << "(): " << SplashCtrl::GenerateVersionInfo(' ');

	Ctrl::SetUHDEnabled();
	Ctrl::SetDarkThemeEnabled();
	...snip...
	LoadSkinSetting();

	// HERE IS A CLEAR POINT WHERE I CAN CHANGE THE SKIN ONCE

	// first line in ide/main.cpp where the GUI is used


This won't work when the user changes skins from settings, but as you said, people don't change skins that often.

But if you:

mirek wrote on Tue, 23 April 2019 10:04

Fixable, just forgot to fix it.

...we may not have a global way to change skins, but in my apps I can emulate the "OnSkinChange" skin invalidation by calling a couple of SetSkins and recreating some borders, so no big issue for me.

For SetDarkThemeEnabled, I propose something like:

void SetDarkThemeEnabled(darkSkin = Ctrl::AutodetectDarkSkin);

with

Ctrl::AutodetectDarkSkin autodetecting and behaving like old SetDarkThemeEnabled(true)
Ctrl::DarkSkin always dark, with SetDarkThemeEnabled(true) and sEmulateDarkTheme always true
Ctrl::WhiteSkin always light, with SetDarkThemeEnabled(false) and sEmulateDarkTheme always false

And bool IsSystemThemeDark() made public.
Re: U++ 2019.1.rc4 released [message #51659 is a reply to message #51647] Wed, 24 April 2019 00:57 Go to previous messageGo to next message
Klugier is currently offline  Klugier
Messages: 627
Registered: September 2012
Location: Poland, Kraków
Contributor
Hello,

I aligned some of TheIDE icons as well as this from CtrlLib. Can you guys test and let me know (Tom and cbpporter) - what do you think about this alignment? I would be grateful for your opinions - not all icons are fixed, but some of them are (like main TheIDE toolbar now should display icons correctly on dark theme).

Sincerely,
Klugier


Ultimate++ - one framework to rule them all.
Re: U++ 2019.1.rc4 released [message #51662 is a reply to message #51647] Wed, 24 April 2019 08:13 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12017
Registered: November 2005
Ultimate Member
cbpporter wrote on Tue, 23 April 2019 09:55

For SetDarkThemeEnabled, I propose something like:

void SetDarkThemeEnabled(darkSkin = Ctrl::AutodetectDarkSkin);

with

Ctrl::AutodetectDarkSkin autodetecting and behaving like old SetDarkThemeEnabled(true)
Ctrl::DarkSkin always dark, with SetDarkThemeEnabled(true) and sEmulateDarkTheme always true
Ctrl::WhiteSkin always light, with SetDarkThemeEnabled(false) and sEmulateDarkTheme always false

And bool IsSystemThemeDark() made public.


Well, it is worth to keep in mind that the whole mechanism of dark theme in Windows is probably temporary solution. What we are doing there is to emulate dark mode even as Microsoft does not support it for good old win32 applications. It is very likely that this will change and the whole emulation and color conversion for S colors will be done by Win32.
Re: U++ 2019.1.rc4 released [message #51671 is a reply to message #51662] Wed, 24 April 2019 11:37 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1391
Registered: September 2007
Senior Contributor
mirek wrote on Wed, 24 April 2019 09:13

Well, it is worth to keep in mind that the whole mechanism of dark theme in Windows is probably temporary solution. What we are doing there is to emulate dark mode even as Microsoft does not support it for good old win32 applications. It is very likely that this will change and the whole emulation and color conversion for S colors will be done by Win32.

I wouldn't place my bets on that. And dark mode is included now, so you literally opened Pandora's box. This will be for me a two week 6 hours/day project.

I'm trying to do some minimal changes to U++ that will fix some visual issues while improving usability and compatibility with my themes.

So...

Issue #1: SetDarkThemeEnabled

Problem: SetDarkThemeEnabled is IMHO poorly names, because it is more like EnableDarkModeEmulationByColorInvertingIfWindowsIsInDarkMode .

As a compromise, I added an enum that by default behaves the same, but you can force dark mode or light mode at will.

I tested things and they look compatible.

I would like this change or something that achieves the same results. Feel free to rename stuff.

Thank you!

Attached files in zip.

PS: Do you prefer a better way for patch submission?
  • Attachment: patch1.zip
    (Size: 24.45KB, Downloaded 20 times)

[Updated on: Wed, 24 April 2019 12:04]

Report message to a moderator

Re: U++ 2019.1.rc4 released [message #51672 is a reply to message #51671] Wed, 24 April 2019 12:04 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1391
Registered: September 2007
Senior Contributor
Edit:
After further testing, I think solution 2 is better.

Solution 1 was present in the attachment, so I am attaching solution 2 in a new post.


Issue #2: High contrast
I have spent a great deal of time looking over Win32 chameleon and now have a good idea on what the OS gives us when it comes to skinning. You weren't kidding when you said that dark mode was "emulation".

With so little information, inverting was pretty clever. I set up more nuanced processing for my skin, but it only works for a single windows skin. So your solution is more universal and probably the best we can do.

The problem is that it results in a high contrast themes.

The problem is that light skins is not black text on white background, only for some controls. There are gray backgrounds, shadows and overall a nice array of colors. On the other hand, if you look at our color palette colors, in dark mode, they are purely white on black background. A "normal" dark skin will be many shades of gray and some gray tinted colors. Pure white and black are taboo.

As I said above, this is not fixable with current support, but we can add some customization.

Let's start small: BlackBorder (and WhiteBorder).

The issues is that BlackBorder is SColorText, so black normally. And white in dark mode. Fair enough. But BlackBorder is used by BlackFrame in CtrlLib too as a border, and there it is similar but different from ViewBorder.

In some skins it might make sense for it to be black/white, but for a modern look, it would be probably SColorText/SColorShadow in light/dark. But this would ruin Draw.

Solution 1:
Leave things as they are, but allow us change BlackBorder color. This way I can skin this in my code.

This solution is a bit awkward since we already have:
const ColorF *BlackBorder();

Maybe there is a better way?

I have attached this solution.


Solution 2:
Make BlackBorder truly black (might or might not be useful to customize) and change BlackFrame to not use black border, but a customizable Chameleon value.

So BlackFrame would have 4 colors to customize and maybe some extra goodies, like border width customization?

And BlackBorder would be used by Draw to draw black borders and never by GUI, while the GUI would sue BlackFrame, a far more flexible solution? With image and hotspot support?

  • Attachment: patch2.zip
    (Size: 10.53KB, Downloaded 17 times)

[Updated on: Thu, 25 April 2019 10:52]

Report message to a moderator

Re: U++ 2019.1.rc4 released [message #51673 is a reply to message #51672] Wed, 24 April 2019 12:33 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1391
Registered: September 2007
Senior Contributor
Issue #3: DateCtrl an EditField fixes
I fixed some colors in DateCtrl and co and in EditField, the null image is now scaled.
  • Attachment: patch3.zip
    (Size: 18.30KB, Downloaded 15 times)
Re: U++ 2019.1.rc4 released [message #51677 is a reply to message #51673] Thu, 25 April 2019 10:57 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1391
Registered: September 2007
Senior Contributor
Issue #2: High contrast
I's attaching my new preferred method.

Draw remains unchanged. BlackBorder is black and works good on white surfaces and of course inverted for dark mode.

BlackFrame is a dark border, but used for GUI mostly. This one still has the same colors, but this one is customizable.
  • Attachment: patch4.zip
    (Size: 13.27KB, Downloaded 16 times)
Re: U++ 2019.1.rc4 released [message #51687 is a reply to message #51677] Fri, 26 April 2019 08:52 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12017
Registered: November 2005
Ultimate Member
Thanks, I appreciate your efforts.

That said, priority right now is to release. I do not like to change internals right now.

After that, I will be glad to do so. But perhaps it is a good time now to define desired outcomes.

Certainly there will be changes to CtrlCore/CtrlLib to make skinning better.

We might consider to abandon "skin only at the start of app" too.

It looks like the result of your work will be a bunch of new skins. Years ago I wished to have custom skins as packages in uppsrc/art. Unfortunately, the only addition there so far is "BlueBars". I am hopeful that your new skin will find a way there... That said, make sure they are self-contained (all they need must be in the package).

Mirek
Re: Dark theme issues [message #51690 is a reply to message #51581] Fri, 26 April 2019 10:49 Go to previous messageGo to next message
Oblivion is currently offline  Oblivion
Messages: 577
Registered: August 2007
Location: Turkey
Contributor
Hello,

I've noticed one "paper-cut" type problem with repo (svn) dialog. Credentials button is not aligned/anchored to right (it won't update its horz. position on resize)

A more serious one is with declaration to definition conversion method, in Assist.cpp, ln. 952:

It nows removes "override" keyword from definitions, but it does not remove "final" keyword.

And IMO the method used for removing the "override" keyword is somewhat problematic:

String AssistEditor::MakeDefinition(const String& cls, const String& _n)
{
	String n = TrimLeft(_n);
	n.Replace("override", "");
	n.Replace("final", ""); // <-- this should be added. It's a practical solution, but is it really OK?


Reason:
my_foo::finalize();
my_foo:navigationoverridehandler();


Parser will remove the "final" and "override" words from the method names...

Now, this is probably a corner case, but still, it might be annoying fo the user.


Best regards,
Oblivion





[Updated on: Fri, 26 April 2019 11:30]

Report message to a moderator

Re: Dark theme issues [message #51694 is a reply to message #51690] Fri, 26 April 2019 11:21 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12017
Registered: November 2005
Ultimate Member
Fixed
Re: U++ 2019.1.rc4 released [message #51697 is a reply to message #51687] Fri, 26 April 2019 18:01 Go to previous message
cbpporter is currently offline  cbpporter
Messages: 1391
Registered: September 2007
Senior Contributor
mirek wrote on Fri, 26 April 2019 09:52

Something that can read and write system colors, you can code in it, outputs in Painter for smooth scaleable graphics, but the end result will of course be cached as an image like Chameleon does today.

I'll look over Esc/Usc and see if they can be hooked up for Painter...


This is off-topic, but I'm surprised Esc isn't integrated with Painter.

Works really well! I see a lot of potential in it! All we need is a bit of color API and helpers. And function overloading if it is not supported Smile.

index.php?t=getfile&id=5835&private=0
  • Attachment: esc.png
    (Size: 70.65KB, Downloaded 52 times)

[Updated on: Fri, 26 April 2019 21:09]

Report message to a moderator

Previous Topic: New dark theme thread
Goto Forum:
  


Current Time: Tue Sep 17 14:19:29 CEST 2019

Total time taken to generate the page: 0.01238 seconds