[lazarus] Win32/GTK Colors
aj_genius at hotmail.com
Wed Sep 18 20:31:40 EDT 2002
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
>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..
> 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..
MSN Photos is the easiest way to share and print your photos:
More information about the Lazarus