[lazarus] delphi compatibility

Marc Weustink Marc.Weustink at cuperus.nl
Wed Feb 6 08:50:51 EST 2002

+ From: Michal Bukovjan [mailto:michal.bukovjan at openone.cz]
+ Marc Weustink wrote:
+ >+ From: Mattias Gaertner [mailto:nc-gaertnma at netcologne.de]
+ >+
+ >+ On Mon, 04 Feb 2002 23:02:39 +0100
+ >+ Michal Bukovjan <michal.bukovjan at openone.cz> wrote:
+ >+
+ >+ > Mattias Gaertner wrote:
+ >+ >
+ >+ > [...] GTK themes [...]
+ >+ >
+ >+ > 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,
+ >
+ >For compatibility I won't drop them
+ >
+ Sure. Question is, how long it will take when Windows 200x
+ get their own themes and Borland drops them first. I think it
+ is just a matter of time.

FYI, win3.1 and newer already have a kind of themes.

I won't expect Borland to drop properties etc that fast. When new theme
options are avialable, I expect that they will be added.

+ >One thing I read here is a lot of GTK. We should be carefull
+ >in putting to much GTK specific features in the LCL. That way
+ >we go the same way as why this discussion started, to much
+ >focussed on one widgetset.

+ I was using this GTK as an example. The same actually applies
+ to Qt - in fact there are some talks between KDE and Gnome
+ developers (or GTK and Qt) to unify the theme format for both
+ platforms (maybe it already happened). In fact, the only platform
+ I can think that lacks proper themeing is Windows.

Define proper :-) I've no problems with the current windows implementation.
But that's a matter of tase (Personally I don't care about themes)

+ >+ > 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
+ >
+ >Compatebility is not only needed for forms. What is the need for a
+ >translated dfm, if you can't use the code with it ?
+ >
+ I thought the importer would do some sort one way of Delphi->Lazarus
+ property mapping. Why couldn't I use the code then?

Then you have to scan all the code. Beleave me that's not going to work. If
you happened to work with a translated version of VBA, you know what I mean.

+ >+ > 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),
+ >
+ >IMO, we do. You can't get rid of them, or you would have to
+ >create your own IDE and break all compatebility. IE, unable
+ >to use external components like the editer we are currently using.
+ >
+ I am not talking about removing those functions. I was more thinking
+ about creating some abstract interface along the way which we would
+ prefer to use over time.

Aha.... there we are on the same line. A while ago we had such a discussion
on the devel list. We din't come to a conclusion.

+ >+ > 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?)
+ >
+ >{$DEFINE} We don't need them.
+ >
+ We don't need what? Better design or features of other platforms?

Extra flags. IMO they are handled in the interface.

+ >+ > >>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.
+ >
+ >Here we are talking GTK again.
+ >
+ Yes, because these widgets simply do some things differently, though
+ functionally equivalent with Win32. Here would be place for abstract
+ functions. The WinAPI calls simply cause horrible hacks to
+ twist GTK or some other platform work by means of Windows API calls.

I'm not against abstract functions (or an abstract widgetset), but there are
some issues about that

1) The current interface has to be reworked completely. IMO there are some
way to do it smoothly, but thats future.

2) You still need winAPI. Not all software is pure written in LCL.


More information about the Lazarus mailing list