On Tue, 14 Sep 2004 12:56:50 +0100, Simon Large <slarge@blazepoint.co.uk> wrote:
> I have been looking at the TBlame colourising scheme with a view to sending
> a patch. I found out why I am getting funny colours, and it is simply that
> you can't do plain arithmetic reliably on a COLORREF, because you get
> integer overflows in the colour components. For example, my highlight
> background is 0x80.00.00. If you subtract 0x30.30.30 you get 0x4f.cf.d0
> which is a different colour, but probably not what you wanted; the red and
> green components have underflowed to a high value.
/me hitting my head against the next wall
Yes! You're right.
> It would be easy to add a function to adjust one colour component at a time
> to avoid this, but you then run into another problem. The user may not be
> using the default colour scheme; in fact he (she) may be using a high
> visibility scheme which is based on white-on-black, in which case you need
> to make the backgrounds lighter, not darker.
>
> The workaround I came up with was a function which computes a colour which
> is somewhere between the text and background colours using a percentage
> value:
>
> COLORREF MakeInterColour(COLORREF Text, COLORREF Bgnd, int Slider)
>
> Slider is a percentage:
> Slider <= 0 returns Text
> Slider >= 100 returns Bgnd
> Values in between return a colour which lies between the two.
Good idea!
> Ideally to get the right luminance it should convert both colours from RGB
> to HSL, interpolate the in-between colour, then convert back. But that is
> possibly more complicated than is strictly necessary!
Conversions between RGB and HSL are very complicated, and AFAIK can't
be really done 100% accurate anyway. So I suggest to use the simpler
function you mentioned above.
> The final hurdle is that I do not understand the intent of some of the code.
> In DrawBlame(), you have code to set colours based on the revision and
> author of the line that the mouse is over, or that has been selected.
> However, I cannot see any instance where the author is used. It seems to be
> overridden by the revision every time. I am not sure what you intended here.
> Should there be additional code to determine whether the mouse is over the
> author or rev column?
Not quite: if you select a revision, the author which committed in
that revision might have committed other revisions too. That's where
the 'selected author' comes into play.
The same is with the 'mouse author' - the revision the mousepointer is
over was done by one author, which might have committed other
revisions too.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Sep 14 15:33:36 2004