Dark Theme in my program?

[flowCRANE]

I've installed this package — https://github.com/zamtmn/metadarkstyle

Great job, unfortunately there are bugs that spoil the rendering of some components and affect the operation of Lazarus itself (e.g. you can't minimize Lazarus by clicking the button on the taskbar, the main window disappears and never appears again). Another problem is that the designer is also converted to a dark theme, which causes some colors and some component settings to change on the form opened in the designer and these changes are later compiled into the our program's exe, which is unacceptable. If possible, the designer should have a system look, by way of exception.

Also I changed some colors because the text had too much contrast (instead of RGB 255,255,255 I used 225,225,225, it's much better). If possible, I also suggest changing the color of the window's title bar, because it has too much contrast (actualy full contrast — black bar and white text). You can replace the title bar background color to RGB 20,20,20 and the window caption text to 225,225,225.

I reported problems with this package on GitHub — https://github.com/zamtmn/metadarkstyle/issues. I hope these problems can be fixed.

[zamtmn]

@furious programming
Thanks! I will try to fix and improve. but as they say - patches are welcome))

[flowCRANE]

No problem! I intend to use this package and dark Lazarus on an ongoing basis, so if I find any issues, I will be sure to report everything to GitHub meticulously. However, when it comes to patches, it will be worse here, because I'm not a Win32 API specialist, so I don't know if I will be able to help in this topic. But if I can, I'll try to help.

Once again, many thanks to everyone who contributed and will contribute to the creation of this package!

[d7_2_laz]

About the contrasts: please take into account that's heavily a matter of taste.
I'm fully happy with the contrasts as they are now.
So i'm concerned here that, by applying lowered contrasts, good readability might be touched without any need.
(Imo it could be a typical case for an option. Constrasts as they are, vs. dimmed contrasts. Just another field for itself. But that's not my vote here).

A separate story might be some 'disabled' colors. which appearing sometimes not very optimized for good readability. Here i'd agree.

[flowCRANE]

About the contrasts: please take into account that's heavily a matter of taste.

Not completely. Look around, see what programs and websites that have been implementing the dark theme for a long time look like. Examples include Microsoft Edge, VS Code, Youtube, GitHub and many others. If you use white for text, its background is dark grey. A black background is not used at all, and if it is very dark grey (almost black), then the text is grey, at most light gray.

The reason is that white text on a black background is too contrasty, and after a short time, reading makes the white lines of text burn in on the eyes — when you move your gaze to something else (even off-screen), you can still see those lines, which is very disturbing. Therefore, the right choice of colors is very important.

This package allows to apply arbitrary colors to interface elements (currently dark predefined colors), so ultimately it would be very good if it added the ability to configure colors to the IDE, similarly to the colors of the code editor. If the user can change them freely, then every user will be satisfied, and the package will be extremely valuable.

[d7_2_laz]

Without regard how other programs might behave, someone can be fully satisfied with the color set as it is.
The ability to configure colors individually would be good, but until someone decides to implement this, i'd think: keep it simple and pragmatic. Maybe via an if/else controlled by a variable (‘use_native’ true/false) deciding which set to use.
Might be hardcoded defaulted somehow. No problem to change this variable each time a new version is picked up. Better than to alter a whole set. Each easy measure to preserve backwards compatibility would be fine.

[d7_2_laz]

Actually i'm still struggling with more basic things. I try to achieve in my apps that they, when loading, do appear instantly and smoothly, without noticeable color change operations. Actually i cannot fully reach this with the dark theme.
One does notice that with rather complex apps ie.when loading data during the FormCreate, not with easy examples.
So i did speak above about the white flashing at the treeview loading.

Another candidate, and i hope it's the last one, is the StatusBar. For a short period of time you can see that it noticeably changes it's color from gray to dark ('darkening applied too late'). I'm fully aware it is not due to the dark theme files itself. rather due to Windows mysteries, doing some stuff that sometimes is hard to influence.
So the overall impression of the start phase: it appears somehow restless, not all of a piece.

As i assume that i'm not the only one who does notice this: how do you handle that??
I attach a short video of the status bar at loading time; double-click on the GIF for to play it.

[flowCRANE]

Without regard how other programs might behave, someone can be fully satisfied with the color set as it is.

Of course, I was satisfied with the existing colors. And then I checked the source code and realize that all colors are stored in the ordinary array of TColor filled by hand (using RGBToColor function), so I changed few of them to better match my requirements.

The ability to configure colors individually would be good, but until someone decides to implement this, i'd think: keep it simple and pragmatic.

Fair enough but, as I wrote above, all colors are stored in the internal array, so the only thing to do is expose them — add some getters/setters and that's it. I bet that the current version of the package is able to apply colors at any moment during runtime, so this feature should be realy simple to do — just change the colors and apply changes (repaint app windows).

The only thing to consider is to decide if this package should be still called "dark", since it even currently allows to use any color palette, not only dark. In my opinion, it makes no sense to limit this package to the dark theme, because Lazarus users may want a blue code editor, for example, and blue IDE windows would be perfect for that. I dreamed of a dark theme, so I'm happy to use the current form.

Actually i'm still struggling with more basic things. I try to achieve in my apps that they, when loading, do appear instantly and smoothly, without noticeable color change operations. Actually i cannot fully reach this with the dark theme.

[...]

As i assume that i'm not the only one who does notice this: how do you handle that??

I've noticed this, but the flashing of the window in white is so short-lived that it doesn't bother me at all. Still, it would be nice if the window wasn't flashing white.

The plus is that the IDE is very fast anyway. Yesterday I tested a separate build of Lazarus that I built on Qt5 and it runs much slower despite using the Optimized IDE mode. So performance-wise, it's still great.

[d7_2_laz]

allows to use any color palette, not only dark

I've had the same association too. Nevertheless i guess a couple of people are happy to have the chance to get also a dark version beneath their regular ones.
I agree that the principle has room and chances for further development.

the flashing of the window in white is so short-lived that it doesn't bother me at all. Still, it would be nice if the window wasn't flashing white.

Fully right. That's already a luxury area, more a nice-to-have than a must-have.
The desire comes up when once having started the original (light) version again, seeing the difference in the start phase.
But: it's not the window, it is (resp. was) the treeview and the statusbar. So the idea to solve those particularly.
I already tried to enforce an early repaint of the StatusBar, but that did not have the desired effect. Btw one hss to be prepared for obscure side effects when experimenting in this area.
If nothing helps I'll ignore it, but was hoping someone had already solved this. As said, high-level tuning area.

[d7_2_laz]

Crazy enough, but ...:

Code: Pascal  [Select][+][-]

1. procedure TFormMain1.FormCreate(Sender: TObject);
2. var ....
3. begin
4.     uWin32WidgetSetDark.ApplyDarkStyle;
5.     StatusBar1.Visible := False;
6.     // Do some loading stuff here ..
7.     StatusBar1.Visible := True;
8. end;

That already helps to make it more smooth, as it noticeably shortens the time where a light gray statusbar within the dark environment will appear.
Of course the issue is not entirely gone, but it's far less obvious, so that in sum a more consistent impression is preserved.
 

(Also it could be considered to move the 'loading stuff' to FormActivate, FormShow, .., but i didn't want to restructure the prog only for this particular issue).

[d7_2_laz]

@furious-programming   (cc:  zamtmn and Erik@T)

about your other issue with the Statsubar (#5, StatusBar is not rendering correctly):
https://github.com/zamtmn/metadarkstyle/issues/5

--> seems that Erik already created a solution for that, See reply #29 within this thread.
(the dividers are painted, although not very recogizable imo).

[d7_2_laz]

The divider (separator) color is easy to change here.

Code: Pascal  [Select][+][-]

1. function StatusBarWndProc(Window: HWND; Msg: UINT  ...........
2. ........
3.   if Msg = WM_PAINT then
4. ........
5.        // LCanvas.Pen.Color:= SysColor[COLOR_BTNFACE];     // as is
6.         LCanvas.Pen.Color:= SysColor[COLOR_GRAYTEXT];     // or whatsoever

[zamtmn]

d7_2_laz
>>See reply #29 within this thread
Commited, thanks!

[flowCRANE]

The problem with the status bar still exists but, now is the problem is different — there are too many separators rendered, see the attachment (extra separator is rendered over the filename, in the code editor window). And please, try to use the same color for the separators as for the statusbar frame. This will match the style of the original rendering.

BTW: if something is reported on GitHub issues, please give feedback on GitHub as well. My statusbar issue was closed there without any comment and I didn't know what was going on. I just came across this thread and noticed that the discussion is going on here. Let's try to keep order so as not to get lost in all this.

[zamtmn]

>>The problem with the status bar still exists but, now is the problem is different
Fixed try2))

>>please give feedback on GitHub as well
I closed it with a commit, there was a link to the forum in the commit text, I had nothing to add there, except to say thank you again))
Can you open the complaint again?

>>And please, try to use the same color for the separators as for the statusbar frame
TStatusBar doesn't have a frame, suggest a concrete color