[lazarus] delphi compatibility

Mattias Gaertner nc-gaertnma at netcologne.de
Mon Feb 4 18:32:55 EST 2002

On Mon, 04 Feb 2002 23:02:39 +0100
Michal Bukovjan <michal.bukovjan at openone.cz> wrote:

> Mattias Gaertner wrote:
> [...] GTK themes [...]
> 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).

Hmm. I agree, that the gtk has too many attributes to put them all onto the first level. The object inspector would show so many attributes, that the user will do more scrolling than setting properties. An ExtendedStyle property collecting all seldom used styles is needed.
But I don't think, that all style properties should be only accessible via this style object. Remember, we are talking about VISUAL components. Users expects to set some important styles at once in the OI.

> 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

Delphi compatibility is not only a one time transformation. Like Delphi, Lazarus needs components. The more compatible lazarus is, the more components we can get. And I'm sure we want many components.

> Note that Kylix and Delphi 6 breaks some compatibility as well, so we 
> should not be holier than Borland!

Hmm. Tricky. Their license makes it hard for free source to be holier. ;)

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

Then we do, what normally is done: either we add one or we add a new function.
BTW: records as parameters are not very fast.

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

IMO this is not base stuff. This should be handled by components.


More information about the Lazarus mailing list