State of codehighlighting.cpp

[Milian Wolff]

On Wednesday 15 April 2009, David Nolden wrote:
> Am Mittwoch 15 April 2009 21:55:43 schrieb Milian Wolff:
> > On Wednesday 15 April 2009, David Nolden wrote:
> > > Am Mittwoch 15 April 2009 20:58:48 schrieb Milian Wolff:
> > > > You misunderstood me: I don't see a necessity to make the colors
> > > > configurable.
> > > >
> > > > I just don't see why we generate the _base_ colors (see color wheel /
> > > > HSV). Those could be _hardcoded_! And then we adapt those colors to
> > > > the chosen color scheme (automatically).
> > >
> > > Actually you can try this out(Maybe as an option). It's possible that
> > > this leads to better colors, but it'm not sure. The question is, what
> > > would you do differently than the automatic algorithm? You'd probably
> > > evenly pick colors from the color wheel. Maybe with some small
> > > adjustments, but those might very well be specific to your screen or
> > > your eyes.
> >
> > Zomg - I found the culprit! The colors inside CodeHighlightingColors were
> > hardcoded and never mixed! I've fixed that and will clean up my stuff and
> > then commit it. Or do you want to make a review first?
> >
> > PS: That means that I don't have to change much, i.e. we still do the
> > same, just some more.
>
> If you promise me that it still works normally for light background color
> schemes, you can just commit it. :-)

I still got the problem that I have no clue on how to reliably access the 
foreground color defined for the katepart...

That is a problem when you use a light katepart color scheme with a dark kde 
color scheme or vice versa...

I'll have to wait for an answer on the kwrite ML it seems...
-- 
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/91788139/attachment.sig>