[lazarus] delphi compatibility

[Marc Weustink]

+ 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

+ > also Ctl3d and ParentCtl3d (this was dropped in Kylix anyway).
In later versions of delphi those properties are obsolete (hidden), but
available for  older programs.

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

I think that there isn't a big deal is some rare (or specific) properties
are accessed though a second level (ala Font)

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

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

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

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

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

Also if you pass them as const ? (I expect that to be faster than passing
individual params)

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

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

I see a future of components handling those platform/widget specific tasks
as an extention of the LCL (extention, not core)

Marc