State of codehighlighting.cpp

[Milian Wolff]

On Wednesday 15 April 2009, David Nolden wrote:
> Am Mittwoch 15 April 2009 19:02:28 schrieb Milian Wolff:
> > Hi devels!
> >
> > Since I'm a user of a dark color scheme I want to get support for custom
> > color schemes fixed in KDevelop. I took a look at codehighlighting.cpp
> > and found some "issues" which I'd like to fix / change:
> >
> > 1. why uint instead of qcolor all over the place? There are tons of (imo
> > unneccessary) "casts" due to that. I'd like to move everything to QColor.
>
> Not all over the place, only in the places where the interpolation plays a
> role, and that's already the reason: uint's can be interpolated easily. You
> can only do that with QColor if you first convert it back to uint, so why
> not just keep it as uint? It doesn't matter..

But why store the colors as uint instead of QColor? As you say: uint's are 
required for interpolation, but nowhere else...

> > 2. there's lots of missing documentation / explanation in that file. I
> > myself have never had to do color interpolation or mixing, and am a bit
> > lost on how exactly the interpolate function works. Could someone
> > elaborate? Or maybe give me a link to a explanation, imo this should be a
> > common problem which got solved pretty often.
>
> Interpolating colors is like interpolating anything else, linearly
> transform from one color into the next(Although I'm right now thinking
> whether this is actually correct ;-) )
>
> > 3. Couldn't the whole process be simplified somehow? For example by
> > setting a few defaults for white background / black foreground. Then for
> > custom kate color schemes we adapt our defaults according to a algorithm
> > of our choice.
> >
> > I'm currently writing a little test-app for different color agorithms, if
> > you know any good ones, please let me know!
> >
> > I'll also implement the current algorithm to see how it fares.
>
> What do you mean by "color algorithms"? All the code in there does is
> generating a predefined set of colors, that differ as much as possible from
> each other, using the color wheel(try the HSV color model in gimp to see it
> illustrated). There's not more you can do.

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?

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...

> 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.

-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20090415/3b4b0a12/attachment.sig>