[lazarus] delphi compatibility

[Michal Bukovjan]

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.

>
>+ > 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.
>
>One think 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.

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

>
>
>+ 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.
>
>Sure, I agree on that. Second let's fucus on what we're trying to do, get a
>stable Delphi lookalike IDE. If all our components are working etc... then
>think of adding and extending 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),
>
>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.

>
>
>+ > 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
>
>Thats indeed emulation, if you create yyour own params, you don't do the
>emulation :-)
>
>+ > 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?

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

Michal