State of codehighlighting.cpp

[David Nolden]

Am Mittwoch 15 April 2009 20:22:12 schrieb Milian Wolff:
> But why store the colors as uint instead of QColor? As you say: uint's are
> required for interpolation, but nowhere else...
Doesn't matter at all, change it if you like, and if it really makes the code 
simpler.

> Why not create a set of predefined colors? That is: pick some colors by
> hand and "hardcode" them. I don't see why we need to do that automatically,
> esp. when the amount is fixed. Or should that one day be variable?
Yes, this way we can eventually make the count of colors configurable. Also we 
can add other ways of distinguishing colors. I think there is enough hard-
coded colors in that file.

> And with "color algorithms" I mean the logic behind adapting the
>
> calculated/predefined color to the current color scheme:
> > Once those colors are chosen, they are damped/blended by the
> > user-configured value with the normal foregrond color, to make it less
> > annoying.
> > There is one problem: See codehighlighting.cpp:127, I haven't found time
> > to find out how to correctly extract the text-editor foreground color.
> > That would be the first thing you have to do to make it work with dark
> > color schemes. Actually, I think when that works, the problem with the
> > auto-generated colors would be solved, so the only remaining problematic
> > colors would be the hardcoded ones.
>
> I have already written an email to the kwrite mailing list, lets hope I get
> a reply there. For the time being I've used kcolorscheme which gives me the
> current global KDE color scheme (I have a kate color scheme resembling it).
>
> Still, the mixing is not enough here, I get many unreadable colors. See for
> example the debug output for my current branch:
>
> text color: 0xffd4d2cf background color:  0xff201f1f
> color 0 interpolated from 0  <  1326 : 0xfff91e1e ratio: 4.32537
> color 1 interpolated from 132  <  1326 : 0xfff9621e ratio: 5.67538
> color 2 interpolated from 264  <  1326 : 0xfff2a51e ratio: 8.59897
> color 3 interpolated from 396  <  1326 : 0xff80d21e ratio: 9.42254
> color 4 interpolated from 528  <  1326 : 0xff1ef232 ratio: 11.5523
> color 5 interpolated from 660  <  1326 : 0xff1ebfcd ratio: 7.94216
> color 6 interpolated from 792  <  1326 : 0xff1e66f9 ratio: 3.60435
> color 7 interpolated from 924  <  1326 : 0xff3d1ef9 ratio: 2.24088
> color 8 interpolated from 1056  <  1326 : 0xffa41ef9 ratio: 3.43341
> color 9 interpolated from 1188  <  1326 : 0xffd21e94 ratio: 3.62533
>
> ratio is the return value for
>
> KColorUtils::contrastRatio( generatedColor, backgroundColor );
>
> The documentation says that the ratio should be 5 or higher to be
> readable...
Are you sure that backgroundColor() as well as standardColor have correct 
values? If they have, then the problem should at least be solvable by changing 
the "Local Variable Colorization Intensity" in the Language Support settings.

> > To solve that one, I think the proper solution would be getting the kate
> > editor background color, and then automatically manipulating all colors
> > so they have some minimum contrast to that background. I've done
> > something similar in
> > kdelibs/kate/completion/expandingtree/expandingdelegate.cpp, where I just
> > invert the color if it doesn't have enough contrast to the background. As
> > a first try, you could just copy the code from there, and do the same
> > thing. The only problem is that some colors might look ugly when they are
> > inverted. It would be better keeping the same color tone, just making it
> > darker or lighter.
>
> There's KColorUtils::darken and ::lighten, I'll try to see how far I can
> get that.
Might be worth a try. Or eventually just manipulate the foregroundRatio in 
generateColors() to increase the contrast, this will probably do nearly the 
same thing.

Greetings, David