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

Now I understand this.

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)

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

Marc

Why ? For the active theme every syscolor can be mapped to RGB. Or do I mis something ?

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.

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.

THese requirements will break some code. Thing we tried to avoid in the past.

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.

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.

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

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

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

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

I agree sort of.. make as close of an aproxmation as possible, and try to avoid the problem colors..

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

I am working on getting System Colors to match the System theme under GTK, as much as is possible. For most those things that have been implemented they work great. However there are a few things which need ironing out, that will affect both the Win32 and GTK interfaces.

Issue #1:

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

Issue #2 :
In GTK there are different "system" colors for different widget modes. This means that what Font/Brush colors are depends on what state the Widget being drawn is in. For Completely custom drawn widgets this is not an issue, however for theme drawn widgets, such as TSpeedButton, this causes problems with the font color. The background is already taken care of in the interface side, but the font is drawn by calling to DrawText, which does not have any passed parameters which define what mode the Widget is in. My proposal for this, is that we create a set of Text Drawing routines for Theme compatibility. On Win32 these routines would simply ignore any extra passed params, and call to the standard DrawText, ExtTextOut, TextOut routines. But in GTK, the extra params would determine what FONT & GC would be used to draw the Text..

Comments, Questions, Ideas??

Andrew

_________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com

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.

:-)

Ah, yeah, ofcoarse

Like StockObjects

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

Hmm... bright idea :-)

Agree.. (nothing to add to this)

Marc