Version: 4.1.0 (using KDE 4.5.3) OS: Linux It'd be nice to have the ability to change the colours in the code browser. I'm using a dark theme, because it's easier on the eyes. But the code browser (the "tooltip" that appears when you move your mouse over a function/variable/etc) has a white background with black text and it hurts my eyes :) It's not using the kde theme, and there are no options to change it. Reproducible: Always Steps to Reproduce: Move your mouse over a function, or use the "Code Browser" tab at the bottom. Actual Results: A white tooltip with black text appears. Expected Results: A black tooltip with white text should appear (well, a configurable tooltip; I'm sure many like the black-on-white). I was asked at the forums to post this as a bug.
I can confirm this issue. I'm using KDevelop 4.1.1. Default background and foreground colors really shouldn't be hard-coded but configurable. Even if some things assume white background, it doesn't stop from using, for example, gray background with blue tint or whatever else user would like. Same goes for foreground color. For me this is a problem because white background color hurts my eyes, especially when code browser' window is large; but even when it's small, it's still feels very uncomfortable for my eyes. I tried to fix this myself, but I can't find where are these values are set in the source code of KDevelop/KDevPlatform (white background and black text for the code browser). I would appreciate if somebody could suggest where are they set. Maybe I can find some free time and create proper fix (a patch) for this by making these values configurable from the GUI.
abstractnavigationcontext.cpp (loc 84f in git master): // since we can embed arbitrary HTML we have to make sure it stays readable by forcing a black-white palette m_browser->setPalette( QPalette( Qt::black, Qt::white ) ); if you remove it, you'll easily end up with black text on black background, since most HTML pages (and hence embedded documentation) only sets a foregroundcolor but no background color.
Created attachment 54191 [details] This patch forces default foreground color instead of black with default background > abstractnavigationcontext.cpp Thank you very much for pointing out the location. > if you remove it, you'll easily end up with black text on black background First I thought of a possibility to make it configurable, but it is pointless because use of "m_browser->setPalette..." for this purpose is ugly (it doesn't really control foreground color in almost all practical cases) so it should be removed and replaced with something else. Simplest solution is to remove useless (note: not all but only useless) instances of color=#000000 (everywhere where no background color is specified), effectively enabling default foreground color (that's what users expect to see). I really don't understand why somebody used color=#000000 without any necessity - it shouldn't be there in such cases; so by removing it we are simply fixing broken HTML. I wasn't able to find a situation where this solution wouldn't work as expected. Can somebody test attached patch and confirm that it works well (in Code Browser)? Note: it does not matter if you are using bright or dark theme - this solution should work for everybody. If any problems with the patch will be found - let me know, I will try to fix them.
if we'd now include a page that does this: <p style="background-color:#ffffff;color:#000000">text</p> it would break. Not to speak of other ways "black" can be written in CSS that would still break (color:black; color:#000; color:rgb(0,0,0); color:rgba(0,0,0,0);). Not to say that there could be other dark foreground colors hardcoded. And it would also need to be done in expandingtree.cpp loc 48f. And QRegExp is notoriously slow. All in all this just looks hackish. It would be better to find out where the hardcoded black/dark foreground comes from and try to fix that. Btw.: have you tried user-css to overwrite (!important) some colors?
> if we'd now include a page that does this: > <p style="background-color:#ffffff;color:#000000">text</p> > it would break Actually no, it wouldn't because background is specified so color will be untouched in this case. But yes, patch I have attached in #3 is just a quick hack: as I explained in previous message real source of problem are unnecessary instances of color=#000000 (and anything that does not fix actual source of problem is always a hack, no matter what you try to override foreground or background color). > Btw.: have you tried user-css to overwrite (!important) some colors? I thought of that first. But obviously I can't override ALL colors in font tag (or any other for that matter - that would break everything); how to override only specified color(s) in CSS only in cases where no background is specified - I have no idea (I doubt this is possible). BTW, I have encountered such problems before - in fact almost all Web-pages in the Internet have them, and I ended up creating very complex rewriters of CSS/HTML to fix them because use of custom stylesheet was not enough so all web-pages are displayed how I like them. However, this definitely isn't something acceptable for KDevelop for many obvious reasons (most important reason - that would be very terrible and complex hack that does not deal with actual problem but simply hides it). Real fix would be to remove both "m_browser->setPalette..." and source of useless instances of color=#000000 - then there would not be any need in any kind of hack. Currently I'm not sure where are useless instances of "color=#000000" are coming from. I will investigate this when I have more free time and hopefully will be able to find clean fix.
I almost forgot to say. I have published here a hack to fix this problem and asked to test it in order to make sure that useless instances of color=#000000 are only major problem currently in the Code Browser (I was not proposing it as a real fix to be accepted). So, if somebody can confirm that the patch works well everywhere that would help (I want to know if there are any more real world problems with colors in Code Browser or not). If you find any problem with colors in Code Browser that this patch does not fix please tell me how to reproduce - I will try to find *proper* fix for any additional problems with colors in Code Browser (I guess I didn't say that properly in #3 at the end so this is most likely why you misunderstood me). Thanks.
ah ok, I misunderstood your hack, but my "negative-example" is valid if you write it this way or similar: <p color="#000000" style="background:#000">asdf</p> It's by far too limited and I will never merge such a hack into kdevelop. And I think you still did not understand: We don't create that HTML, it might come from *anywhere*. 4.2 e.g. comes with support to embed *arbitrary* .qch files (e.g. kde api documentation, qt documentation, ...) and that can contain whatever HTML the creator put in there. While the current situation is not nice, it at least works reliably.
> It's by far too limited and I will never merge such a hack into kdevelop. Well, as I said, hack I provided was not proposed for inclusion, just for testing, and as I explained earlier it was intended only for *one specific* problem and nothing else. It definitely was not intended to "fix" arbitrary documents or to be useful with any possible CSS/HTML. I think it is better to discuss what is acceptable. Here is two possible ways that I personally consider as clean: 1) Make "m_browser->setPalette..." set colors configurable by an user but as default use black foreground and white background. Also add support for a custom stylesheet. This way does not change what currently is the default, just adds more options for an user. 2) An accessibility option to invert intensities of all explicit colors in Code Browser. I have tested this possibility already and it works very nice. I have no clean implementation yet but if this is acceptable I will implement it cleanly when I have enough free time. Important note: when turned off (and that's will be the default if implemented) it will not introduce any overhead. If this option is enabled, it will invert all color' intensities in the way that does not change colors themselves (for example, dark green will become bright green, black will become white, etc.). Example of how this works can be found in many programs which have similar accessibility option: for example, okular or kpdf (these programs provide similar option as monochrome gradient between two user defined colors but what I'm proposing does not change colors but only their intensities when enabled by an user). This accessibility option is very useful for people for whom white background feels very uncomfortable and/or black text is hard too read no matter what background color is used. This way will not change what currently is the default, will not change anything when when turned off (and that's the default) - it simply adds an accessibility option very useful for some people, and works only when turned on by an user. There are three possibilities: implement both #1 and #2, or implement #2 only and when the accessibility option is turned on, don't use m_browser->setPalette. It is possible to implement #1 only but that's definitely will not give enough flexibility to make all users comfortable and personally I don't have motivation to implement #1 only, I'm motivated to implement either both #1 and #2, or at least #2 only but, obviously, implementing both #1 and #2 provides more flexibility for an user. What do you think? What possibilities are acceptable?
*** Bug 270813 has been marked as a duplicate of this bug. ***
@L. Rahyen: user css is complicated but powerful. would be OK for a hidden option but not sure whether it's worth it. 2) sounds nice but I'm not sure how easy it is to implement. Also for documentation it will create problems as soon as colors are documented (as the colors will be changed ;-) ) - but imo I see no other way to solve this accessibility issue.
> sounds nice but I'm not sure how easy it is to implement It's not too hard to cover all possibilities in HTML/CSS. More important is to implement it in KDevelop cleanly so it would be acceptable. > for documentation it will create problems as soon as colors are documented > (as the colors will be changed ;-) ) Colors will not change, only their intensities will: "for example, dark green will become bright green, black will become white, etc.". I tried inverting colors too but it looks worser (and much less intuitive) than inverting colors intensities. Use of this option accessibility will not create any problem: it will be intuitive for everybody who wants it, and like in other KDE programs like kpdf or okular with similar accessibility option, it will be turned off by default. User who decides to turn it on will know what to expect. By the way, accessibility option to invert colors intensities is very similar to what okular and kpdf do when configured to invert document colors with difference that my approach preserves all RGB components and colors themselves. So as I understand implementing both approaches is acceptable (of course if implementation itself will be good enough). Great. > but imo I see no other way to solve this accessibility issue. This is true. Most HTML documents are like PDF documents: they must be processed to look good with non-default background and foreground colors. This is exactly what kpdf and okular can do and kdevelop cannot (yet). After a month or two when I finish some urgent projects (in my everyday work) hopefully I will be able to find enough free time to implement these accessibility options. I will attach my implementation here for review when it will be ready.
sounds good but please use reviewboard for the patch once it's done: http://git.reviewboard.kde.org/
Created attachment 108626 [details] Tooltip color with Breeze-Dark theme I still have this issue 7 years after it was submitted. Is there any activity planned on this?
Patches welcome ;)
I may sound naive, but why do we even accept arbitrary HTML as documentation source? Can't we use e.g. gumbo to strip all non-text tags? Qch doesn't use many anyways.
Quite probably, yes. But the colours we use ourselves are not background-independent either (I think they are fixed, e.g. the green for the types etc). It's certainly not an undoable or even super difficult task, it's just that somebody would have to do it.
For the record, I don't see value in HTML-formatted docstrings in tooltips at all. Text is just fine, for everything else you want to use the documentation browser anyways.
I think having (simple) HTML there makes sense in a few cases. Think of doxygen-style @code/@endcode sections, which libclang turns into <pre/>-style text sections. Or doxygen lists turned into HTML listings. This would look odd when loosing the HTML-formatting in the tool tip browser.
Yes, some of the HTML, like headings and paragraphs needs to be pre-rendered somehow. But you can probaly render it to good plaintext relatively easily.
*** Bug 395857 has been marked as a duplicate of this bug. ***
*** Bug 257958 has been marked as a duplicate of this bug. ***
*** Bug 390459 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/340
A possibly relevant merge request was started @ https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/370
Git commit d30fed992438e5cdbd917d7f67a4cd449c40622c by Milian Wolff, on behalf of Martin Seher. Committed on 28/08/2022 at 10:14. Pushed by mwolff into branch 'master'. Apply color scheme to code browser tooltip do not force black on white palette adept colors when dark color scheme is used - make dark text colors brighter - when background color is set keep bg and fg colors Also changes the colors in the quick open menu M +5 -7 kdevplatform/language/duchain/navigation/abstractnavigationwidget.cpp M +71 -0 kdevplatform/util/widgetcolorizer.cpp M +6 -0 kdevplatform/util/widgetcolorizer.h M +6 -4 plugins/quickopen/expandingtree/expandingtree.cpp https://invent.kde.org/kdevelop/kdevelop/commit/d30fed992438e5cdbd917d7f67a4cd449c40622c
*** Bug 460466 has been marked as a duplicate of this bug. ***