|
|
|
Home » U++ Library support » Look and Chameleon Technology » Dark theme issues
|
|
|
|
|
|
| Re: U++ 2019.1.rc4 released [message #51640 is a reply to message #51636] |
Tue, 23 April 2019 08:58   |
cbpporter
Messages: 1427
Registered: September 2007
|
Ultimate Contributor |
|
|
mirek wrote on Mon, 22 April 2019 21:03cbpporter wrote on Mon, 22 April 2019 16:09Yeah 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. 
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 |
 |
mirek
Messages: 14257
Registered: November 2005
|
Ultimate Member |
|
|
cbpporter wrote on Tue, 23 April 2019 08:58mirek wrote on Mon, 22 April 2019 21:03cbpporter wrote on Mon, 22 April 2019 16:09Yeah 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.
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 |
cbpporter
Messages: 1427
Registered: September 2007
|
Ultimate 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 #51671 is a reply to message #51662] |
Wed, 24 April 2019 11:37 |
cbpporter
Messages: 1427
Registered: September 2007
|
Ultimate 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 278 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 |
cbpporter
Messages: 1427
Registered: September 2007
|
Ultimate 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 253 times)
[Updated on: Thu, 25 April 2019 10:52] Report message to a moderator |
|
|
|
|
|
|
|
|
|
| Re: Dark theme issues [message #51690 is a reply to message #51581] |
Fri, 26 April 2019 10:49 |
Oblivion
Messages: 1206
Registered: August 2007
|
Senior 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
Github page: https://github.com/ismail-yilmaz
upp-components: https://github.com/ismail-yilmaz/upp-components
Bobcat the terminal emulator: https://github.com/ismail-yilmaz/Bobcat
[Updated on: Fri, 26 April 2019 11:30] Report message to a moderator |
|
|
|
|
|
| Re: U++ 2019.1.rc4 released [message #51697 is a reply to message #51687] |
Fri, 26 April 2019 18:01 |
cbpporter
Messages: 1427
Registered: September 2007
|
Ultimate 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 .
-
Attachment: esc.png
(Size: 70.65KB, Downloaded 481 times)
[Updated on: Fri, 26 April 2019 21:09] Report message to a moderator |
|
|
|
Goto Forum:
Current Time: Fri May 09 12:04:38 CEST 2025
Total time taken to generate the page: 0.02723 seconds
|
|
|
Members
Pages
Help
Register
Login
Home
