[lazarus] Win32/GTK Colors

[Andrew Johnson]

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

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

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

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

exactly.

Andrew

TTFN
Genius(in name only)

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com