Forum > Lazarus Extra Components
Synedit: Too late to remove hardcoded colors and use system colors instead?
prof7bit:
I keep noticing instances all the time where people have left the synedit colors on their default hardcoded values (which were clearly choosen to match the default light windows colors), this has happened even in the Lazarus IDE itself (I am submitting pull requests for every instance of this I am becoming aware of).
If I were in the position to be authorized for invasive decisions I would probably by now have changed the default hardcoded colors in TSynEdit and its surrounding components to consequently use system colors, I would do it in such a way that the 90% who use it on windows (where there exist only light color themes) would not see any difference and on dark themes it would then automagically[TM] look just as nice and natural as it does on light themes.
The question now is this: Changing such an old default value is an invasive change. Although most people would not notice anything if it is done carefully some might be forced to adjust their colors.
Contra:
* might impact a certain fraction of existing applications
Pro:
* Many still unfixed "Dark Theme Problems" will automatically fix themselves
* the overwhelming majority of users would not notice any difference because
- they are using a light theme and are not aware of it at all
- they are already using their own colors anyways
* people who will have to adapt to this change because they intentionally want a white synedit everywhere can do so without forcing them to rewrite any of their code, the needed changes are very limited and uncomplicated, just a few clicks in the object inspector.
* Almost all other controls are already defaulting to system colors, this would remove an unexplained inconsistency.
So the question is: Do we dare to make this change once and for all? My answer would be a resounding yes!
marcov:
The problem is that system colors don't configure the highlighter.
For contrast, if you change e.g. the background colour to the theme you must also select other colors to match.
prof7bit:
I would also propose something I have been doing for quite a while in my own applications:
* a few more colors that span the range between clWindow and clWindowText in steps of 25%, 50%, 75% (or maybe even finer), this can be used for gutter, gutter separator, fold lines, etc., I also use it for thin grid lines, etc.
* two sets of "colorful" colors (used for highlighing or plotting curves), one of them adapted to bright themes, the other adapted to dark themes. On start of the application I compare the luminance of clWindow and clWindowText and if text is brighter than background I am on a dark theme and use the second set.
prof7bit:
See screenshot.
Probably too radical to add to these clAutoXxx colors to the Graphics unit, but the concept itself has proven to be very useful.
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---unit AutoColors; {$mode ObjFPC}{$H+} interface uses Graphics; const clWindowText20: TColor = clNone; clWindowText40: TColor = clNone; clWindowText60: TColor = clNone; clWindowText80: TColor = clNone; // default color names from the VGA standard, // will stay unmodified on light themes clAutoAqua: TColor = clAqua; clAutoBlack: TColor = clBlack; clAutoBlue: TColor = clBlue; clAutoFuchsia: TColor = clFuchsia; clAutoGray: TColor = clGray; clAutoGreen: TColor = clGreen; clAutoLime: TColor = clLime; clAutoMaroon: TColor = clMaroon; clAutoNavy: TColor = clNavy; clAutoOlive: TColor = clOlive; clAutoPurple: TColor = clPurple; clAutoRed: TColor = clRed; clAutoSilver: TColor = clSilver; clAutoTeal: TColor = clTeal; clAutoWhite: TColor = clWhite; clAutoYellow: TColor = clYellow; type TThemeForce = ( forceDark, forceLight, forceAuto ); function Mix(A, B: TColor; Ratio: Integer): TColor;function IsDarkTheme: Boolean;procedure UpdateThemeColors(Force: TThemeForce=forceAuto); implementation function Mix(A, B: TColor; Ratio: Integer): TColor;var RgbA, RgbB: LongInt; Compl: Integer;begin RgbA := ColorToRGB(A); RgbB := ColorToRGB(B); Compl := 10 - Ratio; Result := RGBToColor( (Red(RgbA) * Compl + Red(RgbB) * Ratio) div 10, (Green(RgbA) * Compl + Green(RgbB) * Ratio) div 10, (Blue(RgbA) * Compl + Blue(RgbB) * Ratio) div 10 );end; function IsDarkTheme: Boolean;var ColW, ColT: LongInt;begin ColW := ColorToRGB(clWindow); ColT := ColorToRGB(clWindowText); Result := Red(ColW) + Green(ColW) + Blue(ColW) < Red(ColT) + Green(ColT) + Blue(ColT);end; procedure UpdateThemeColors(Force: TThemeForce);var Dark: Boolean;begin case Force of forceDark: Dark := True; forceLight: Dark := False; forceAuto: Dark := IsDarkTheme; end; clWindowText20 := Mix(clWindow, clWindowText, 2); clWindowText40 := Mix(clWindow, clWindowText, 4); clWindowText60 := Mix(clWindow, clWindowText, 6); clWindowText80 := Mix(clWindow, clWindowText, 8); if Dark then begin // tweaked for dark theme clAutoBlack := clWhite; clAutoWhite := clBlack; clAutoAqua := Mix(clAqua, clBlack, 5); clAutoLime := Mix(clGreen, clYellow, 4); clAutoSilver := Mix(clSilver, clBlack, 5); clAutoYellow := Mix(clYellow, clRed, 5); clAutoBlue := Mix(clBlue, clWhite, 6); clAutoNavy := Mix(clBlue, clWhite, 4); clAutoOlive := Mix(clOlive, clWhite, 2); clAutoGreen := Mix(clGreen, clWhite, 2); clAutoMaroon := Mix(Mix(clMaroon, clRed, 2), clWhite, 3); clAutoPurple := Mix(clPurple, clWhite, 5); clAutoTeal := Mix(clTeal, clWhite, 2); end else begin // defaults for light theme clAutoBlack := clBlack; clAutoWhite := clWhite; clAutoAqua := clAqua; clAutoLime := clLime; clAutoSilver := clSilver; clAutoYellow := clYellow; clAutoBlue := clBlue; clAutoNavy := clNavy; clAutoOlive := clOlive; clAutoGreen := clGreen; clAutoMaroon := clMaroon; clAutoPurple := clPurple; clAutoTeal := clTeal; end;end; initialization UpdateThemeColors;end.
Martin_fr:
--- Quote from: prof7bit on September 27, 2021, 12:05:43 pm ---Pro:
* Many still unfixed "Dark Theme Problems" will automatically fix themselves
--- End quote ---
This is the sort of unfounded claim that goes nowhere.
I mean, I could advertise any change I want with "Fixes tons of other problems". If I do not name them, and do not show how it fixes them, then where is the value in the statement.
--- Quote ---So the question is: Do we dare to make this change once and for all? My answer would be a resounding yes!
--- End quote ---
While my gut feeling is that my answer wont be that resounding, at this time my answer does not exist.
There is not even an example. If you are that sure of it, then surely you have that config already on your system?
Where is:
- the image how it looks on diff themes (you could use the sample text from the IDE options)
the "auto colors" picture is not SynEdit
- the new code in TSynEdit, and (some) highlighters
OR BETTER: an exported IDE config, to show how it looks? (What better use for the export button)
Also what is the exact proposal?
First of all you said: "changed the default hardcoded colors in TSynEdit".
That is change what happens when I put a TSynEdit or a TSynPasSyn (highlighter) on a TForm in my own project.
But you also wrote: "this has happened even in the Lazarus IDE".
Actually, technically: No.
In the IDE the colors do not come from the defaults in the HL. Or at least the majority does not: Comment, Number, Keyword, ... do not come from the defaults hardcoded in the SynEdit package.
The IDE has its own defaults for those.
<off topic>IIRC, in the IDE it even went the opposite way, some colors were system colors, which did not mix with hardcoded colors, so they got replaced.</off topic>
So which one do you propose to change
- SynEdit
- the IDE
- both
Because my reply would depend on that.
SynEdit:
"Add them" => Ok
"Replace the old" => No.
I could see them being added as a choice. But I would not entirely throw out the old ones.
I would be open to talk about which ones become default. Though if the default were to be changed, that poses the issue what happens to existing apps.
The IDE:
Any existing installation must not be touched, even if it uses the default colors.
That would mean, if a change was made, a new scheme would be added. This new scheme could then become default for new installations.
I.e no pre-existing user config. User config is kept by default when you uninstall. So people re-installing can keep their settings.
This is not a yes. But it is a "might be worth exploring the idea".
IMHO such a scheme could first be offered as a separate download ("userschemes").
This would allow feedback to be collected:
1) people approving of the colors, for their desktop defaults
2) people having the option to propose diff defaults (in terms of existing system colors)
It would also show, if there is any interest at all.
As a side note:
The rest of the IDE does not follow themes (yet).
So this would lead to a mismatch between IDE and editor.
And, but this is probably (almost certainly) a minority issue:
Not everyone wants the editor to follow their system defaults.
I have tons of VM for testing, many of them (Linux) come with dark defaults. Yet I want my editor to be light.
Navigation
[0] Message Index
[#] Next page