[lazarus] Win32/GTK Colors

[Marc Weustink]

At 20:34 18-9-2002 -0400, you wrote:
>On Thu, 19 Sep 2002 00:37:36 +0200
>"Marc Weustink" <marc at dommelstein.net> wrote:
>
>>??? wont break vs. updating an interface ???
>
>I am not certain I understand.. but the interface is the level at which 
>things like this should be handled anyway.. so I don't consider it 
>breaking compatibility, but rather adding/fixing functionaility.. Brush's 
>and Pen's still accept an RGB value, just like windows, so nothing there 
>is broken. But it now accepts Delphi SystemColors as well which wasn't 
>supported by Windows..but IMO should have been. So what I am saying is 
>that old code will work with the new design, but code made for the new 
>design may not work with Win32/Delphi Design anymore..

Ahhhh

>  I don't think porting Lazarus code to Delphi is an issue,  and 
> converting a Lazarus program to straight Win32 API calls is simply absurd.

:-)

>>Do I understand it correctly if I say tha getBrush now supports bot a RGB 
>>color as a Syscolor ? That seems OK.
>
>Sort of.. it can't accept the SysColor directly beause these are values 
>0-25, which are of course real colors, so it instead accepts a Delphi 
>System color, clScrollbar, clWindow etc, which are the Systemcolors or'ed 
>with $8000000 instead.

Ah, yeah, ofcoarse

>>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)
>
>There is a CreateSysBrush.. but  this returns a static item which can't be 
>modified deleted etc..

Like StockObjects

>>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.
>
>I agree sort of.. make as close of an aproxmation as possible, and try to 
>avoid the problem colors..
>
>>[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
>
>Right this makes sense from a MS point of view, and the themed part can be 
>to a certain extent  imitated 95% accurately with GTK.. but for the 
>standard routines it is not so easy. In XP there is a color "scheme", and 
>a color/pixmap "theme",

Where AFAIK the color "scheme" is replaced by the colors from a theme (if 
you're using a theme)

>under GTK there is only one or another never truly both. So for certain 
>types of color fills etc. Standard routines need to be able to find a 
>middle-ground.. for now the most sensical way from a GTK+ standpoint is to 
>draw with the theme engine for those colors even in standard mode... from 
>a more MS approach, the best way to handle this is it to  create a cached 
>pixmap on setting of the theme which can be used to draw the actual GTK 
>value, and take a pixel sampling of the result to aproximate a common 
>color which would match the theme semi-accurately..

Hmm... bright idea :-)

>both ways will break true one to one compatibility between GTK and Win32 
>drawing, so in my opinion it makes most sense to pick which one matches 
>the systems default.. in this case GTK draws with a theme on certain 
>values by default, therefore our default routines should as well, themed 
>or otherwise.. and thus for lcl component drawing the preffered way would 
>be to avoid this issue entirely by only using Themed drawing routines for 
>everything which uses a system "color" value, unless you know for certain 
>that there is no possibility of it being a non-color value.. for instance 
>Default Font colors..

Agree.. (nothing to add to this)

Marc