[lazarus] Win32/GTK Colors

Marc Weustink marc at dommelstein.net
Wed Sep 18 18:34:46 EDT 2002

At 14:52 18-9-2002 -0400, Andrew Johnson wrote:
>On Wed, 18 Sep 2002 00:00:51 +0200
>"Marc Weustink" <marc at dommelstein.net> wrote:
>>>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 ?
>Initially thats what I thought too but.. thats the point.. mapping to 
>every active theme is NOT possible, about 50% of SysColors can be 
>accurately mapped 70% of the time. this is why the newSyscolors routine is 
>disabled by default. Even my new routines are only accurate for about 70% 
>of the colors 85% of the time. Full support is NOT possible, and for the 
>most part never will be.(but who really cares about innactivegradient etc..)

>>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.
>You missunderstand.. I do not mean the RGB value, but the Colorref value.. 
>aka clBtnFace etc.. IN Win32 and Delphi if you wan't to draw with the 
>button face color you convert the value to a real color by calling to 
>SysColor(COLOR_BTNFACE), and use the returned value.. since a lot of the 
>time in GTK the button face is a pixmap, this is immpossible.

[1] see end.

>So instead we send the actual color passed..and on the other side say if 
>clBtnface then..else etc.. This doesn't break compatibility with code at 
>all so long as the Win32 interface is updated properly to handle this sort 
>of thinking..

??? wont break vs. updating an interface ???

Do I understand it correctly if I say tha getBrush now supports bot a RGB 
color as a Syscolor ? That seems OK.

>it only means that Lazarus/LCL code won't be backwards compatible to 
>Delphi.. and really once the Win32 version is done who is going to 
>complain about that? So long as the programs themselves are compatible...
>>  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.

Now I understand this.

>>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.
>This IS what I am doing.. but its not what is expected to be done on 
>Windows.. Windows expect the real RGB value.

I haven't been GDI programming for several months now, so some details 
might have faded :) (I assumed that something like CreateSolidBrush also 
accepts Syscolors, but apperently not)

>>THese requirements will break some code. Thing we tried to avoid in the past.
>Shouldn't break anything to my knowledge.. though we will wait and see.
>>>Issue #2 :
>>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.
>This is exactly the sort of thing I meant.. I don't want to change the 
>default routines if at all possible. Though I hadn;t realized WinXP had 
>done this. I will see what I can find out on MSDN.

While I read more and more on these things, themes, compatibility and 
colors, it looks like the general idea is (at least in XP) when one uses 
the old API functions to draw items, one gets the old style items. When one 
uses the the new functions, one gets themed items.
IMO we could do the same, when drawing things we could get the colors as 
good as possible matched, but thats it.

[1] If for instance we want to draw an ownerdraw button, we should use the 
new functions to draw a button with a themed face.

Looking at XP, if you want to draw something like a button, you have to 
call DrawThemeBackground and DrawThemeEdge whereas if you dont do theming 
you would have called FillRect and DrawEdge


More information about the Lazarus mailing list