Please see configurablecolors.cpp file, that contains a bunch of colors that are hardcoded and cannot be changed. These colors play really bad with dark color schemes. These colors should be configurable inside the color scheme instead.
Their brightness is adapted to the background brightness though. When I tried, they worked fine with dark schemes too.
Created attachment 113560 [details] Dark theme with hardcoded KDevelop colors
I think "fine" is a bit subjective here. I just think that all colors should be configurable in the color scheme settings, otherwise it doesn't make much sense to have color scheme settings don't you think? (look at the image I sent in attachment) These are half colors from color scheme and half colors from hardcoded ConfigurableColors. To me this just doesn't feel right. I would be nice if such colors can go to the color scheme settings instead and be fully configurable.
On my screen the attachment looks ok, for my taste. I think there are two reasons why this is not currently there (not saying it shouldn't be): a) we do not have an interface to add additional config colors to KTextEditor's color schema editor; and b) it's a lot of colors to configure, right now it is a lot easier to get a dark background because the 20 or something colors we have automatically kind of adjust to that.
The problem is that I would like to use my own color scheme and this "hardcoding" complicates my work. To me it sounds absurd that I can change a color of a damn breakpoint dot, but I cannot change a color of a class, for example.
I understand your complaint. You are also not the first person who is unhappy with this. I'm just saying fixing it is (both technically and logically) not as simple as just adding five entries to a config list, except if you are okay with having two separate dialogs for configuring colors (which I wouldn't like to have) ...
Why it's so impossible to add like 3 more options to the existing color scheme? I mean if I check out the current Color Scheme there is a lot of options (and a lot of ISO C++ options as well) and I would say that maybe 80% of cases are already covered. The remaining 20% would be possible to add too no? We talk about "class", "variable", maybe "member variable" - these are not really bound to C++ either, pretty generic attributes.
Because the color scheme manager is provided by the KTextEditor component, which knows nothing about these colors. If you would add them there, kate users would have like 15 colors to configure there (it's not so few: 8 rainbow variable colors, class, function, public member, private member, typedef, macro, enum, public self member, private self member is already 17 and I probably forgot some) which do nothing ever in their application. It is possible to do this but it requires adding an interface to make it possible and it requires some code to generate sensible defaults for these colors (can probably re-use the current one) from the kate schemas which do not contain them. So far the suffering was not big enough for anyone so they would have done this.
The question is whether there is a will to progress with this or not. If it's so much of a problem then I would understand it and this can be closed. I just wanted to contribute and give some opinions about this as I'm a daily user and this makes my use of KDevelop uncomfortable as I cannot change these colors without going to the sources and recompiling it.
I mean why not to talk to Kate developers and agree on new fields that even Kate can support in the future? As you said, it would be absurd to have 2 color settings. Or maybe KDevelop can use its own settings and have them extended. I just don't know, anything seems better than a bunch of hardcoded colors that cannot be changed.
I'll put it on my mental "to-discuss-at-akademy"-list. I'm afraid there are a few things above this priority-wise though.
The kate developers already agreed on a list of color names they commonly need, and came up with something like 10-15 colors. We are not going to be able to add another 15 to these which make sense. And as always, it would be nice to have this fixed but somebody needs to invest the time to do it.
I see, you can prob close this one, I have a feeling this would never really be fixed anytime soon.
Alternatively, you have Color Schemas where you have "Default Text Styles" and "Highlighting Text Styles". In "Highlighting Text Styles" there is a million highlight types, so maybe adding "Semantic Highlighting" as an extra type and defining the colors there would work as well. Just trying..
I found that there are these additional fields in color scheme that don't belong to standard C++: Qt Macros Qt Types Qt Classes Qt Functions Standard Macros Standard Classes Boost stuff Types (_t, _type) Statics (s_) Globals (g_) Data Members (m_) Many GCC Extensions And still, there is a reasoning against adding something really generic like Class, Typedef, Macro to default text styles? I mean if not used by the KTextEditor these default text styles can be used as default values for language specific styles (for example in Scripts/PHP there is already "Classes" field). In addition, in ISO C++ there is nothing like `s_` is a static, etc, these are also pure convenience concepts, so I see no reasoning against generic class, typedef, etc. Maybe even reusing these for highlighting would work, like "Data Members" (m_) could be as well used by semantic highligting for class members, Statics as well... What I mean that I think most colors can be reused from colors that are already defined, and some would have to be added. My point is that we can have Qt Macros, Qt Types, Qt Classes (which would be unused by semantic highlighting), but not C++ Macros, Types, Classes, which are more likely in a generic C++ project. My main problem here is that I watch these colors maybe 12 hours a day and I cannot really change them without recompiling KDevelop. And since I usually use white theme during a day and dark theme in night times I don't see a simple way of doing this without having color schemes working :( I think the status should also change from UNCONFIRMED. I believe this is an issue and it should be fixed somehow.
Also interested in seeing this worked on.
Marking this as "confirmed, wishlist". The current behaviour is expected, but could be improved if anyone was interested.
You can just close it, I don't think this will ever be solved anyway. It's kinda pity that I cannot customize colors in a text editor thought.
I think this is a missing features too. It's frustating that i can't change color on some basic "keywords".
*** Bug 410213 has been marked as a duplicate of this bug. ***
I think it would be perfectly fine to have a separate dialog to configure the semantic highlighting colors. It's a different level of code interpretation, so its styling can be separate from purely syntactic highlighting as well.
*** Bug 276057 has been marked as a duplicate of this bug. ***
I must say that I'm slowly moving away from KDevelop. Thanks for not doing anything to make colors configurable!
Patches are, as always, very welcome. No-one's paid to work on KDevelop -- it's all done in our free time, so I might as well thank *you* for not doing anything about it. I have looked at this (and the similarly-popular https://bugs.kde.org/show_bug.cgi?id=257378 ) a couple of times, but I keep getting sidetracked by issues that matter more to my own work (like making sure the Python backend keeps working with new versions of the language). When someone fixes it, it'll be fixed. If you can't wait for someone else to fix it, do it yourself -- fixing bugs that annoyed me was how I got into KDevelop development, and I suspect many others over the years. The nice thing about KDevelop being an IDE is that all our users are programmers...
Hey we ALL have open source project, right? Who is the most proficient person to fix an issue in a project that he knows? You know, I compile my own KDevelop and I really tried to fix it, but if you read the discussion there is some interesting comments: """ I understand your complaint. You are also not the first person who is unhappy with this. I'm just saying fixing it is (both technically and logically) not as simple as just adding five entries to a config list, except if you are okay with having two separate dialogs for configuring colors (which I wouldn't like to have) ... """ So, to tell you something - I have no idea how to fix this even if I allocate time for it. So instead I spend my time on my own projects, because there I have an idea about what to do. I think that this issue is a failure of both KDE and KDevelop teams to cooperate - because KDE team doesn't want properties in color settings that are not used by KTextEditor component and KDevelop team doesn't want its own color settings that would drive the semantic highlighter! Now, tell me how I can fix that? Can you propose how this could be fixed in both KDE and KDevelop so both projects and also users are happy? Because I have no idea and spending time on something that has no chance of being merged doesn't motivate me to do so.
A possibly relevant merge request was started @ https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/338
Git commit 54b3be95cd66f9cf0141031a5d97d4b6a5dc8031 by Milian Wolff, on behalf of Martin Seher. Committed on 01/07/2022 at 08:28. Pushed by mwolff into branch 'master'. Configurable semantic colors Add a page under _Color Themes -> Highlighting Text Styles -> KDevelop/Semantic Colors_ that allows the configuration of the semantic highlight colors. - When the _Local colorization intensity_ is bigger than zero then the rainbow colors are used for local variables like before, overwriting the corresponding configured colors - A _Global colorization intensity_ less then 255 (max) will still cause a blending of the global colors - _Bold font for declarations_ will make the declarations bold in addition to the bold settings from the config dialog So a _Local colorization intensity_ of 0 and a _Global colorization intensity_ of 255 should be set when the exact configured colors are desired. See also: https://invent.kde.org/kdevelop/kdevelop/uploads/500467bc355906d363e3a76a9044e138/ColorConfig.png M +1 -0 kdevplatform/language/CMakeLists.txt M +15 -5 kdevplatform/language/highlighting/codehighlighting.cpp M +3 -0 kdevplatform/language/highlighting/codehighlighting.h M +133 -5 kdevplatform/language/highlighting/colorcache.cpp M +9 -0 kdevplatform/language/highlighting/colorcache.h M +3 -0 kdevplatform/language/highlighting/configurablecolors.cpp A +42 -0 kdevplatform/language/highlighting/syntax/kdevelop-semantic-colors.xml A +5 -0 kdevplatform/language/highlighting/syntax/syntax.qrc M +10 -15 plugins/contextbrowser/contextbrowser.cpp M +2 -2 plugins/contextbrowser/contextbrowser.h https://invent.kde.org/kdevelop/kdevelop/commit/54b3be95cd66f9cf0141031a5d97d4b6a5dc8031
reopening because the change had to be reverted
Git commit b0f16d56efacf38437fb92771dd7cf780e960151 by Milian Wolff, on behalf of Martin Seher. Committed on 08/07/2022 at 18:25. Pushed by mwolff into branch 'master'. Configurable semantic colors Add a page under _Color Themes -> Highlighting Text Styles -> KDevelop/Semantic Colors_ that allows the configuration of the semantic highlight colors. - When the _Local colorization intensity_ is bigger than zero then the rainbow colors are used for local variables like before, overwriting the corresponding configured colors - A _Global colorization intensity_ less then 255 (max) will still cause a blending of the global colors - _Bold font for declarations_ will make the declarations bold in addition to the bold settings from the config dialog So a _Local colorization intensity_ of 0 and a _Global colorization intensity_ of 255 should be set when the exact configured colors are desired. See also: https://invent.kde.org/kdevelop/kdevelop/uploads/500467bc355906d363e3a76a9044e138/ColorConfig.png M +1 -0 kdevplatform/language/CMakeLists.txt M +133 -2 kdevplatform/language/highlighting/colorcache.cpp M +9 -0 kdevplatform/language/highlighting/colorcache.h A +42 -0 kdevplatform/language/highlighting/syntax/kdevelop-semantic-colors.xml A +5 -0 kdevplatform/language/highlighting/syntax/syntax.qrc https://invent.kde.org/kdevelop/kdevelop/commit/b0f16d56efacf38437fb92771dd7cf780e960151
Git commit 3e9ba9921096396031603a3930c1e01cfff634e2 by Milian Wolff, on behalf of Martin Seher. Committed on 08/07/2022 at 20:23. Pushed by mwolff into branch 'master'. Configurable semantic colors Add a page under _Color Themes -> Highlighting Text Styles -> KDevelop/Semantic Colors_ that allows the configuration of the semantic highlight colors. Additionally, add a "global color source" setting to the language settings. When the latter is set to "From Editor Theme" we will use the colors from the theme as-is without any further blending. _Bold font for declarations_ will still make the declarations bold in addition to the bold settings from the config dialog. Local rainbox colorization is not affected by this at all. See also: https://invent.kde.org/kdevelop/kdevelop/uploads/500467bc355906d363e3a76a9044e138/ColorConfig.png M +7 -0 kdevplatform/interfaces/icompletionsettings.h M +1 -0 kdevplatform/language/CMakeLists.txt M +148 -11 kdevplatform/language/highlighting/colorcache.cpp M +15 -0 kdevplatform/language/highlighting/colorcache.h A +42 -0 kdevplatform/language/highlighting/syntax/kdevelop-semantic-colors.xml A +5 -0 kdevplatform/language/highlighting/syntax/syntax.qrc M +12 -0 kdevplatform/shell/completionsettings.cpp M +3 -0 kdevplatform/shell/completionsettings.h M +6 -0 kdevplatform/shell/settings/languageconfig.kcfg M +6 -0 kdevplatform/shell/settings/languagepreferences.cpp M +147 -67 kdevplatform/shell/settings/languagepreferences.ui https://invent.kde.org/kdevelop/kdevelop/commit/3e9ba9921096396031603a3930c1e01cfff634e2