[kdevelop] [Bug 395856] Semantic highlighting uses hardcoded colors that cannot be changed
https://bugs.kde.org/show_bug.cgi?id=395856 Milian Wolff changed: What|Removed |Added Latest Commit|https://invent.kde.org/kdev |https://invent.kde.org/kdev |elop/kdevelop/commit/b0f16d |elop/kdevelop/commit/3e9ba9 |56efacf38437fb92771dd7cf780 |921096396031603a3930c1e01cf |e960151 |ff634e2 --- Comment #30 from Milian Wolff --- 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-0kdevplatform/interfaces/icompletionsettings.h M +1-0kdevplatform/language/CMakeLists.txt M +148 -11 kdevplatform/language/highlighting/colorcache.cpp M +15 -0kdevplatform/language/highlighting/colorcache.h A +42 -0 kdevplatform/language/highlighting/syntax/kdevelop-semantic-colors.xml A +5-0kdevplatform/language/highlighting/syntax/syntax.qrc M +12 -0kdevplatform/shell/completionsettings.cpp M +3-0kdevplatform/shell/completionsettings.h M +6-0kdevplatform/shell/settings/languageconfig.kcfg M +6-0kdevplatform/shell/settings/languagepreferences.cpp M +147 -67 kdevplatform/shell/settings/languagepreferences.ui https://invent.kde.org/kdevelop/kdevelop/commit/3e9ba9921096396031603a3930c1e01cfff634e2 -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 395856] Semantic highlighting uses hardcoded colors that cannot be changed
https://bugs.kde.org/show_bug.cgi?id=395856 Milian Wolff changed: What|Removed |Added Resolution|--- |FIXED Latest Commit|https://invent.kde.org/kdev |https://invent.kde.org/kdev |elop/kdevelop/commit/54b3be |elop/kdevelop/commit/b0f16d |95cd66f9cf0141031a5d97d4b6a |56efacf38437fb92771dd7cf780 |5dc8031 |e960151 Status|REOPENED|RESOLVED --- Comment #29 from Milian Wolff --- 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-0kdevplatform/language/CMakeLists.txt M +133 -2kdevplatform/language/highlighting/colorcache.cpp M +9-0kdevplatform/language/highlighting/colorcache.h A +42 -0 kdevplatform/language/highlighting/syntax/kdevelop-semantic-colors.xml A +5-0kdevplatform/language/highlighting/syntax/syntax.qrc https://invent.kde.org/kdevelop/kdevelop/commit/b0f16d56efacf38437fb92771dd7cf780e960151 -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 395856] Semantic highlighting uses hardcoded colors that cannot be changed
https://bugs.kde.org/show_bug.cgi?id=395856 Milian Wolff changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #28 from Milian Wolff --- reopening because the change had to be reverted -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 395856] Semantic highlighting uses hardcoded colors that cannot be changed
https://bugs.kde.org/show_bug.cgi?id=395856 Milian Wolff changed: What|Removed |Added Resolution|--- |FIXED Latest Commit||https://invent.kde.org/kdev ||elop/kdevelop/commit/54b3be ||95cd66f9cf0141031a5d97d4b6a ||5dc8031 Status|ASSIGNED|RESOLVED --- Comment #27 from Milian Wolff --- 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-0kdevplatform/language/CMakeLists.txt M +15 -5kdevplatform/language/highlighting/codehighlighting.cpp M +3-0kdevplatform/language/highlighting/codehighlighting.h M +133 -5kdevplatform/language/highlighting/colorcache.cpp M +9-0kdevplatform/language/highlighting/colorcache.h M +3-0kdevplatform/language/highlighting/configurablecolors.cpp A +42 -0 kdevplatform/language/highlighting/syntax/kdevelop-semantic-colors.xml A +5-0kdevplatform/language/highlighting/syntax/syntax.qrc M +10 -15 plugins/contextbrowser/contextbrowser.cpp M +2-2plugins/contextbrowser/contextbrowser.h https://invent.kde.org/kdevelop/kdevelop/commit/54b3be95cd66f9cf0141031a5d97d4b6a5dc8031 -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 395856] Semantic highlighting uses hardcoded colors that cannot be changed
https://bugs.kde.org/show_bug.cgi?id=395856 Bug Janitor Service changed: What|Removed |Added Status|CONFIRMED |ASSIGNED --- Comment #26 from Bug Janitor Service --- A possibly relevant merge request was started @ https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/338 -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 395856] Semantic highlighting uses hardcoded colors that cannot be changed
https://bugs.kde.org/show_bug.cgi?id=395856 Daniel Bermond changed: What|Removed |Added CC||danielberm...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 395856] Semantic highlighting uses hardcoded colors that cannot be changed
https://bugs.kde.org/show_bug.cgi?id=395856 --- Comment #25 from Petr --- 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. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 395856] Semantic highlighting uses hardcoded colors that cannot be changed
https://bugs.kde.org/show_bug.cgi?id=395856 --- Comment #24 from Francis Herne --- 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... -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 395856] Semantic highlighting uses hardcoded colors that cannot be changed
https://bugs.kde.org/show_bug.cgi?id=395856 --- Comment #23 from Petr --- I must say that I'm slowly moving away from KDevelop. Thanks for not doing anything to make colors configurable! -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 395856] Semantic highlighting uses hardcoded colors that cannot be changed
https://bugs.kde.org/show_bug.cgi?id=395856 Francis Herne changed: What|Removed |Added CC||brainstr...@yandex.ru --- Comment #22 from Francis Herne --- *** Bug 276057 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 395856] Semantic highlighting uses hardcoded colors that cannot be changed
https://bugs.kde.org/show_bug.cgi?id=395856 Victor Mataré changed: What|Removed |Added CC||mat...@fh-aachen.de --- Comment #21 from Victor Mataré --- 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. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 395856] Semantic highlighting uses hardcoded colors that cannot be changed
https://bugs.kde.org/show_bug.cgi?id=395856 Francis Herne changed: What|Removed |Added CC||cyberhum...@gmail.com --- Comment #20 from Francis Herne --- *** Bug 410213 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 395856] Semantic highlighting uses hardcoded colors that cannot be changed
https://bugs.kde.org/show_bug.cgi?id=395856 Mattia changed: What|Removed |Added CC||toder...@gmail.com --- Comment #19 from Mattia --- I think this is a missing features too. It's frustating that i can't change color on some basic "keywords". -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 395856] Semantic highlighting uses hardcoded colors that cannot be changed
https://bugs.kde.org/show_bug.cgi?id=395856 --- Comment #18 from Petr --- 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. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 395856] Semantic highlighting uses hardcoded colors that cannot be changed
https://bugs.kde.org/show_bug.cgi?id=395856 Francis Herne changed: What|Removed |Added Status|REPORTED|CONFIRMED Severity|normal |wishlist Ever confirmed|0 |1 -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 395856] Semantic highlighting uses hardcoded colors that cannot be changed
https://bugs.kde.org/show_bug.cgi?id=395856 Francis Herne changed: What|Removed |Added CC||m...@flherne.uk --- Comment #17 from Francis Herne --- Marking this as "confirmed, wishlist". The current behaviour is expected, but could be improved if anyone was interested. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 395856] Semantic highlighting uses hardcoded colors that cannot be changed
https://bugs.kde.org/show_bug.cgi?id=395856 Thibault North changed: What|Removed |Added CC||thibault.no...@gmail.com --- Comment #16 from Thibault North --- Also interested in seeing this worked on. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 395856] Semantic highlighting uses hardcoded colors that cannot be changed
https://bugs.kde.org/show_bug.cgi?id=395856 --- Comment #15 from Petr --- 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. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 395856] Semantic highlighting uses hardcoded colors that cannot be changed
https://bugs.kde.org/show_bug.cgi?id=395856 --- Comment #14 from Petr --- 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.. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 395856] Semantic highlighting uses hardcoded colors that cannot be changed
https://bugs.kde.org/show_bug.cgi?id=395856 --- Comment #13 from Petr --- I see, you can prob close this one, I have a feeling this would never really be fixed anytime soon. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 395856] Semantic highlighting uses hardcoded colors that cannot be changed
https://bugs.kde.org/show_bug.cgi?id=395856 --- Comment #12 from Sven Brauch --- 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. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 395856] Semantic highlighting uses hardcoded colors that cannot be changed
https://bugs.kde.org/show_bug.cgi?id=395856 --- Comment #11 from Sven Brauch --- 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. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 395856] Semantic highlighting uses hardcoded colors that cannot be changed
https://bugs.kde.org/show_bug.cgi?id=395856 --- Comment #10 from Petr --- 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. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 395856] Semantic highlighting uses hardcoded colors that cannot be changed
https://bugs.kde.org/show_bug.cgi?id=395856 --- Comment #9 from Petr --- 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. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 395856] Semantic highlighting uses hardcoded colors that cannot be changed
https://bugs.kde.org/show_bug.cgi?id=395856 --- Comment #8 from Sven Brauch --- 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. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 395856] Semantic highlighting uses hardcoded colors that cannot be changed
https://bugs.kde.org/show_bug.cgi?id=395856 --- Comment #7 from Petr --- 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. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 395856] Semantic highlighting uses hardcoded colors that cannot be changed
https://bugs.kde.org/show_bug.cgi?id=395856 --- Comment #6 from Sven Brauch --- 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) ... -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 395856] Semantic highlighting uses hardcoded colors that cannot be changed
https://bugs.kde.org/show_bug.cgi?id=395856 --- Comment #5 from Petr --- 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. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 395856] Semantic highlighting uses hardcoded colors that cannot be changed
https://bugs.kde.org/show_bug.cgi?id=395856 --- Comment #4 from Sven Brauch --- 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. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 395856] Semantic highlighting uses hardcoded colors that cannot be changed
https://bugs.kde.org/show_bug.cgi?id=395856 --- Comment #3 from Petr --- 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. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 395856] Semantic highlighting uses hardcoded colors that cannot be changed
https://bugs.kde.org/show_bug.cgi?id=395856 --- Comment #2 from Petr --- Created attachment 113560 --> https://bugs.kde.org/attachment.cgi?id=113560&action=edit Dark theme with hardcoded KDevelop colors -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 395856] Semantic highlighting uses hardcoded colors that cannot be changed
https://bugs.kde.org/show_bug.cgi?id=395856 Sven Brauch changed: What|Removed |Added CC||m...@svenbrauch.de --- Comment #1 from Sven Brauch --- Their brightness is adapted to the background brightness though. When I tried, they worked fine with dark schemes too. -- You are receiving this mail because: You are watching all bug changes.
