[lazarus] Win32/GTK Colors

[Marc Weustink]

At 17:11 17-9-2002 -0400, Andrew Johnson wrote:
>I am working on getting System Colors to match the System theme under GTK, 
>as much as is possible. For most those things that have been implemented 
>they work great. However there are a few things which need ironing out, 
>that will affect both the Win32 and GTK interfaces.
>
>Issue #1:
>
>In Delphi and Win32 you have to convert the SysColor value to the actual 
>color. This is very stupid, esspecially for GTK. ColorToRGB makes true 
>theme compatibility virtually imposible.

Why ? For the active theme every syscolor can be mapped to RGB. Or do I mis 
something ?

>So for this reason I have on my system, replaced every place in the LCL 
>and Lazarus that I could find that calls to ColorToRGB, with the actual 
>color reference..

I do not know what to think about this. With actual colors you cant do any 
themeing (what to my knowledge was the primitive idea behind syscolors).
For the moment I'm not to happy about htese changes.

>  This means that the handling of Whether or not it is a System Color has 
> to be done by the interface, which makes much more sense anyway. In GTK 
> this is mostly taken care of with my changes, but in Win32 we have to 
> make sure that everywhere in the interface that it accepts/requires a 
> Color value, that it calls to convert to the actual value for Win32, For 
> instance in CreateSolidBrush, the Color has to be converted to actual 
> color by calling to ColorTORGB before calling to the actual windows routine.

Still not convinced why this should be necesary. Why call ColortoRGB first 
and the call call for instance CreateSolidBrush...
CreateSolidBrush could have converted it anyhow.

THese requirements will break some code. Thing we tried to avoid in the past.

>Issue #2 :
>  In GTK there are different "system" colors for different widget modes. 
> This means that what Font/Brush colors are depends on what state the 
> Widget being drawn is in. For Completely custom drawn widgets this is not 
> an issue, however for theme drawn widgets, such as TSpeedButton, this 
> causes problems with the font color. The background is already taken care 
> of in the interface side, but the font is drawn by calling to DrawText, 
> which does not have any passed parameters which define what mode the 
> Widget is in. My proposal for this, is that we create a set of Text 
> Drawing routines for Theme compatibility. On Win32 these routines would 
> simply ignore any extra passed params, and call to the standard DrawText, 
> ExtTextOut, TextOut routines. But in GTK, the extra params would 
> determine what FONT & GC would be used to draw the Text..

I was already thinking about these in combination of the new XP themeing 
functions. How would Borland handle these etc.

IMO we should not modify the standard API calls. So no extra params to 
TextOut or so.
If we want themeing support, we should use other functions. If we look at 
XP, DrawText draws default text (as we were used to), DrawThemeText draws 
text with respect to a theme. Here we also have params for States, Parts etc.

If we are using something, I think it is a good thing we try to be 
compatible if possible. The reason we could easily port SynEdit was the 
reason we didn't have tho think of adding params to all used functions.