[lazarus] CVS changes

Michal Bukovjan michal.bukovjan at openone.cz
Mon Feb 4 17:02:40 EST 2002

Mattias Gaertner wrote:

>>The idea is to implement more general routines (like the new one 
>>Frame3d) which may not have corresponding counterpart in Windows. The 
>>interfacebase should be platform independent layer, as much as possible,
>>including graphic types 
>>(and possibly others as well, it is just that GTK is about graphics). 
>>The corresponding platform specific interface should implement the 
>>abstract layer, rather than emulate Windows functions.
>The abstract interface should define the base what we want to have on all platforms.
>To get the best from both worlds, emulation has to be done. I see no problem, in emulating windows functions. There are already some parts in the LCL that are more gtk specific than win32 specific, so the win32 interface emulates gtk functionality.
>>BTW, this concept will have to be taken much further, if it should work 
>>properly - think about:
>>- GTK themes, which Lazarus does not respect at all currently.
>Not entirely correct. Graphic systems like the java awt does not respect themes.
>The LCL uses the interface specific widgets/objects/buttons/... . But, you are right, the LCL should respect it more. (e.g. colors, borders)
Actually, I think a lot about breaking Delphi compatibility in this respect.
I think about adding a new Style property, that would be a structure 
holding the same information (or more) as found in gtkrc files.
The information in gtkrc files is currently a superset of what Windows 
have to offer right now, so Windows behaviour would be easily emulated.
It could also save some memory.

The logic would be to have an associated "Style" property, which would 
be of TControlStyle class. If nil, Parent Style would get applied.
We could directly drop properties like Color, ParentColor, Font, 
ParentFont, BorderStyle, and Bitmap property in some cases, also Ctl3d 
and ParentCtl3d (this was dropped in Kylix anyway).
In addition, it would allow us to specify colors, fonts and bitmaps for 
selected states (as in GTK), like Normal, MouseOver, Disabled and other 
states (there are two more defined in GTK).
Once at that, we could kick away Anchor stuff a la Delphi and 
reimplement it Java/GTK like (i.e. you give aspect ratio when resizing 
instead of anchors) - OK, this is something for future.

Just my thought. This would enable us to create a better product than 
Delphi actually is! (At least in some respects). The Delphi 
compatibility could be than solved by some importer unit, which would 
dynamically convert Delphi lfm files into Lazarus units as well

Note that Kylix and Delphi 6 breaks some compatibility as well, so we 
should not be holier than Borland! And for some complex programs, the 
import/porting process stuff is not straightforward anyway.

All we need to do is root out Windowishness out of Lazarus and kick it 
out into interface specific units. I agree that we should keep existing 
Winapi emulation procedures in place, if it proves little trouble to 
support in other targets/platforms and makes life easier for porting 
legacy apps.

>>- keyboard accelerator system
>This is mostly a problem of the menu/popup menu. They need a lot of work.
I would like to look into this now, but what I studied up to now is that 
this one will be the most likely candidate to actually break Delphi 
compatibility (I am not sure at this point, but I think it will not be a 
matter of one API call). We will see.

>>>>Something lik C header files. Maybe in future they could contain 
>>>>abstract class declarations as well, I would like to discuss this first, 
>>>I think, this depends on every case. What classes do you think of?
>>TCanvas, TBitmap - the classes whose methods are actually implemented by 
>>the interface.pp methods it calls.
>>I very much miss C header files here (the split between declaration and 
>>implementation).For instance, we often pass things like LogBrush, 
>>hBitmap, etc. - Windows centric, why not use platform independent 
>>TBrush, TBitmap and work with those?
>1. Delphi compatibility.
>2. most LCL objects can exists without a handle. A handle like hBitmap is the interface specific representation of/connection to a TBrush.
>We should not change the interface functions, just to make them look somewhat nicer.
>But, I think, we can add some alternative functions to the interfacebase, that are more readable. For example functions with parameter names like wParam, LParam are all but helpful.
Again, once we extend the interface for real, Lazarus abstract routines 
(and we will have to do that, we will not do emulating Winapi forever), 
we should use Lazarus/Delphi native types and classes in those procedure 
calls instead of some handles, wParams, adhoc enumerations, etc.
To better understand what I mean (and as an initial proof of concept), 
look at TextRect method of TCanvas as I implemented it, look at the 
TextStyle parameter (and type), and compare with Winapi emulation stuff 
that is called at the end (every attribute stuffed into an Integer, 
which comes from Windows/Qt - what if we need some functionality for 
which there is no flag defined in Winapi?)

>>Again, this was not a problem as we were emulating Windows API, but once 
>>we start to take advantage (or properly use) features of GTK widgets, 
>>which go beyond what emulating Windows API provides, we are at a loss.
>For example?
Any feature found on Linux not covered/present in Windows, or handled by 
Windows in conceptually different way - just off my head:
- window manager communication
- multimedia interfaces (sound, video manipulation)
- accessibility toolkits (Gnome 2)
- shell integration (GNOME vs ShellAPI)

In fact anything that we choose that Lazarus should support in a uniform 
way via different interfaces.

Have fun,


More information about the Lazarus mailing list