Version: (using Devel) OS: Linux Installed from: Compiled sources In the general report, the coverage percentage of each directory is shown with a code of colors. However, the colors used are fixed in the code. The colors should be configurable, as some users may have problems with the default colors (color-blind people, for example). Not only the colors themselves, but also the percentage ranges they are associated to, as different users may have different criteria about the "goodness" of a coverage value. Moreover, right now each color is associated with a full range of coverage (black 0-5%, red 5-30%, orange 30-60% and green 60-100%). It would be better if, optionally, the colors in each range were calculated as a gradient between its begin and end. So the user could choose between using discrete ranges of colors or gradients. Although, as far as I know, KDevelop uses standard KDE colors instead of providing an independent configuration for them, I think that in this case a specific configuration is needed.
Looks like a decent feature to me. +1 :)
To me this seems like over-configurability. What about just using the simple metaphor green=good and red=bad?
> To me this seems like over-configurability. What about just using the simple > metaphor green=good and red=bad? Not my case, but as I said, people suffering from red-green color blindness couldn't discriminate if the coverage is good or bad. And, aside from that, just a two colors code doesn't seem very suitable for code coverage. This is not like unit testing. In fact, right now there is a four color code. But personally I don't like the ranges used, so this is why I'm suggesting that the user should be able to configure it (and, in fact, I am implementing it, not just suggesting ;) ). Moreover, I can't see a problem in over configurability. Are we GNOME now? :P (Just kidding, keep the torches ;) )
Yes, the percentage should be configurable, however the colors themselves need no configuration. Instead the proper KDE API for determining colors should be used. For details see: http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKColorScheme.html http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKStatefulBrush.html In particular IMHO instead of black, green, orange and red one should use NormalText, PositiveText, NeutralText and NegativeText (for foreground). That way we re-use colors that the user has set for an apropriate meaning. I also don't think more than 4 are needed, if you need to have such fine-grained control you should look at the percentages or we could have a way of grouping into 10% groups. More than 4 colours will simply get too colourful.
Configurability is fine, but only if it makes sense. KDevelop3 for example has so many options that you hardly find the ones that are important. Even in KDevelop4 we already have the problem that the configuration menus contain tons of stuff that is useless in most cases. Another problem with over-configurability: If you have it too configurable, you become much less flexible to implement an innovative "real" solution that suits all, you leave the user room to totally screw up his setup and say it's kdevelops fault, and you're tempted to not create a really good well-working default configuration. Consider for example the code-completion: When I started working on it it was extremely configurable, it had a configuration-dialog that filled the whole screen. Now most of it isn't configurable any more, and that allowed me implementing a much more innovative code-completion. Anyway in this special case, I have to admit I've never used coverage, so if the colors are really important there and not just a design gimmick, then it might make sense making them configurable. But it should not be one more page in the configuration menu, rather reachable as sub-menu from within some other related place.
@Andreas Yes that sounds good. And to reduce confusion, it would make sense adding some indicator that allows recognizing the coverage independent of the colors, maybe just the percent-number.
I'm not keen on the {Normal,Positive,Neutral,Negative}Text idea because a/ it's not text ... b/ it's not semantically correct. 'neutral' and 'normal' make no sense wrt coverage ratios. 4-scale / gradient / 10% steps hmm hard to tell which would work best here. These kind of things are easier to judge when actually implemented. @dnolden: - This should definitely go in a separate coverage config page. It's something you typically change once and then never touch again. Adding this to the actual toolview ui/menu seems wrong. Hopefully at some point plugins can be linked to config pages such that only config for loaded plugins are shown. - The percent-number is (obviously) shown already ;)
I fully agree with Manuel. The semantics of the KDE colors are, at least in my opinion, very different from the ones needed here. And I wouldn't expect that the foreground or the background colors of a color scheme are suitable for this. I mean, I would expect a bright green color for very good coverage. But I don't think that PositiveText or PositiveBackground have that color, as that will be difficult to read (although I haven't checked). About the configuration page, I have nothing to add to what Manuel has already said. About the 4-scale / gradient / 10% I have made just a little mock about how a configuration page could look for my proposal. It would let users who like a gradient use a gradient and those who like a N-scale (being N 2, 10 or whatever) use a N-scale. As Manuel said this is something that you change once and never touch again, so I think that using a table is good enough for this purpose. Using a list of custom widgets and things like those seem just unnecessary.
Created attachment 29595 [details] Discrete mode of the color range
Created attachment 29596 [details] Gradient mode of the color range
The point of using those color names is that its consistent across KDE, all positive foregrounds should use Positive text and I believe a 100% coverage is positive. Likewise the negative and neutral part. Being consistent across apps is important. That said, yes this one might be a corner-case where being inconsistent fits better with people expectations.
SVN commit 949802 by danxuliu: Configure colors for directory coverage percentages. ColorRange class and its helper classes map colors to a position in a 0 to 1 range. ColorRange objects can be loaded and saved from a KConfigGroup, and ReportModel was updated to use ColorRange class. LCovSettingsBase and associated widgets were introduced to manage custom data (color ranges) in the configuration module, but keeping the KConfigXT data managed by KConfigXT. Further information in http://reviewboard.kde.org/r/466/ FEATURE: 178470 GUI: M +13 -2 CMakeLists.txt A colorrange.cpp [License: GPL (v2+)] A colorrange.h [License: GPL (v2+)] AM colorrangebar.cpp [License: GPL (v2+)] AM colorrangebar.h [License: GPL (v2+)] A discretecolorrange.cpp [License: GPL (v2+)] A discretecolorrange.h [License: GPL (v2+)] A gradientcolorrange.cpp [License: GPL (v2+)] AM gradientcolorrange.h [License: GPL (v2+)] M +2 -0 lcovconfig.kcfgc M +14 -2 lcovprefs.cpp M +5 -6 lcovprefs.h D lcovprefs.ui AM lcovprefswidget.cpp [License: GPL (v2+)] AM lcovprefswidget.h [License: GPL (v2+)] A lcovprefswidget.ui lcovprefs.ui#943869 AM lcovsettingsbase.cpp [License: GPL (v2+)] AM lcovsettingsbase.h [License: GPL (v2+)] M +20 -11 reportmodel.cpp M +15 -1 reportmodel.h AM stoppointwidget.cpp [License: GPL (v2+)] AM stoppointwidget.h [License: GPL (v2+)] A stoppointwidget.ui M +6 -0 tests/CMakeLists.txt A tests/colorrangetest.cpp [License: GPL (v2+)] A tests/colorrangetest.h [License: GPL (v2+)] A tests/discretecolorrangetest.cpp [License: GPL (v2+)] A tests/discretecolorrangetest.h [License: GPL (v2+)] A tests/gradientcolorrangetest.cpp [License: GPL (v2+)] A tests/gradientcolorrangetest.h [License: GPL (v2+)] WebSVN link: http://websvn.kde.org/?view=rev&revision=949802