Forum > Lazarus Extra Components

Synedit: Too late to remove hardcoded colors and use system colors instead?

<< < (2/2)

prof7bit:
My original proposal was not about the highlighter colors, it was about the synedit itself. For example there are two synedits placed in the makeresstrdlg, they just left the hardcoded colors in place. See my merge request https://gitlab.com/freepascal.org/lazarus/lazarus/-/merge_requests/19

Actually it is not clear why these have to be synedits in the first place, they do not use the highlighter anyways, two memos would have been enough, but I did not want to make this patch too intrusive, I just changed the two offending colors from hardcoded black and white to clWindow and clWindowText.

The IDE in general does adapt to dark themes quite nicely, most of the places where people used for example hardcoded backgrounds and system text colors have been fixed during the last years. If I still spot one I will make a merge request.

The fact that many users are using the light themes for the editor is probably because the IDE is shipping by default only with two usable themes, "default" and "Delphi", both of them are light, the other themes are two nostalgia themes, not really meant to be used, and one ugly joke of a theme called "twilight" which was probably added as some kind of alibi.

Now since the IDE has become quite usable on dark themes we could also think about complementing the two default light themes with two real(!) dark themes (real = ones that are actually designed with some dedication and are meant to be nice and usable). But this is probably a totally different discussion.

My example with the auto colors actually was just an illustration of what I meant regarding finding suitable default colors for highlighters. Unfortunately these are not constants in this implementation, so to integrate something like this properly into the graphics unit would probably mean to introduce a bunch of new system colors or something similar to it and expand the functionality of ColorToRGB() or GetSysColor(), and I doubt it would be easy to convince everybody to get this into the LCL. But it would immediately fix the hardcoded highlighter colors problem.

Martin_fr:

--- Quote from: prof7bit on September 27, 2021, 04:41:22 pm ---My original proposal was not about the highlighter colors, it was about the synedit itself. For example there are two synedits placed in the makeresstrdlg, they just left the hardcoded colors in place. See my merge request https://gitlab.com/freepascal.org/lazarus/lazarus/-/merge_requests/19

--- End quote ---
Ah, but then MarcoV is probably right.

Change those to follow default, and any app using a SynEdit + HL will have issues. Except if the App (like the IDE) sets all the colors to the app's default.

prof7bit:

--- Quote from: Martin_fr on September 27, 2021, 03:17:09 pm ---Also what is the exact proposal?

--- End quote ---
Actually I wanted to test the waters, to see whether any change here had any chance to be accepted at all. It would be quite a bit of work to do it properly (and a lot of testing also) and it would be a waste of time if it turns out that it contradics a higher design philisophy and has no chance of being accepted anways.

Maybe first we could think about something like the auto-colors, it would not need to be all 16 vga colors, 8 colors would probably be enough, but it needs to be implemented in such a way that they are constants and can be used in initializers and selectable in the object inspector. This would need changes in the graphics unit.

Once these are in place we can safely replace the default colors in the highlighters with these new autocolors, change all synedit colors into system colors and then see how it looks on a variety of desktop themes. Would such a thing have any chances of success?

Martin_fr:

--- Quote from: prof7bit on September 27, 2021, 05:01:18 pm ---
--- Quote from: Martin_fr on September 27, 2021, 03:17:09 pm ---Also what is the exact proposal?

--- End quote ---
Actually I wanted to test the waters, to see whether any change here had any chance to be accepted at all. It would be quite a bit of work to do it properly (and a lot of testing also) and it would be a waste of time if it turns out that it contradics a higher design philisophy and has no chance of being accepted anways.

Maybe first we could think about something like the auto-colors, it would not need to be all 16 vga colors, 8 colors would probably be enough, but it needs to be implemented in such a way that they are constants and can be used in initializers and selectable in the object inspector. This would need changes in the graphics unit.

Once these are in place we can safely replace the default colors in the highlighters with these new autocolors, change all synedit colors into system colors and then see how it looks on a variety of desktop themes. Would such a thing have any chances of success?

--- End quote ---

Well as I have indicated, the current code isn't set in stone. So there is room.

1)
I'd like to keep the ability to set the old ones easily (could be a special property/component editor, that just sets all colors with a single click action).

2)
I'd like to be able to load the old lfm with the old default colors.
(see below for an idea)


Then the new defaults (in package SynEdit could be implemented).
Finding and agreeing on good defaults is another matter.

As for more system colors. That needs feedback from other developers too....

But, SynEdit use SysToRgb (or whatever it is called).
It could have its own version of that, and therefore have it's own wide range of "default" colors. ( above MAX_SYS_COLORS ?)

In fact that convertor could be a component. So it would be exchangeable depending on the need of an app.
Ideally colors could be converted at their origin, so they could be cached (should be easy in the "TSyn....Attribute" class, to have a cache of the translation).

Such a convertor component, could help with requirement (2) above: People with old apps, could just add (in code, global initialization section) a call to set the component, so it translates into existing colors. (That is way easier that opening potentially scores of forms, and change the settings in each lfm.)
That way we could do an incompatible change, and say to get the old behaviour, add the following line of code: SetDefaultSynColorComponent(TSynOldColorConvertor); // or similar.
(of course that needs good test, that every color is correctly kept / lots of work)

Above is just a draft. Still needs some good amount of thought.

Navigation

[0] Message Index

[*] Previous page

Go to full version