[lazarus] Win32/GTK Colors

[Andrew Johnson]

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

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

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

Andrew


_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx