[lazarus] delphi compatibility

[Michal Bukovjan]

Mattias Gaertner wrote:

>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, 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.
>
Sure. That is why property editors exist after all.
Just for a record, I studied how it is done in Kylix today. In pursuing 
compatibility, Borland arrived exactly to what I want to avoid. On their 
controls, you can set up *only* Color, and Font.Color (as in Windows) 
and Bitmap, which seems to be new. The problem is, when you use your own 
colors, there is no way to specify the color of font or background for 
disabled or mouseover state.
So when a user applies the right theme, you get unreadable text or funny 
looking hover effects (yellow text on yellow background, or gray text on 
gray background, etc.). I call it plain design flaw.

I will think about this ExtendedStyle some more :-)

>>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).
>>
I wonder how Delphi solves these states under Windows (you can apply 
some colors as well, I think). It is just a cannot check as I don't use 
Windows and Delphi for two years now...

>>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.
>
The more powerful and better designed Lazarus gets, the more developers 
it attracts, the more components will eventually get written or ported.
I think that many components will not be portable anyway, at least not 
those more sophisticated - look at the RX components source - see those 
IFDEFs ? (Win32, WinNT, compiler versions, Delphi versions) - I really 
can't imagine just recompiling that under Lazarus.

>
>>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. ;)
>
As a sidenote, does Delphi 6 (CLX) depends on Qt as in Kylix? Do they 
ship a version of Qt for Windows instead of Windows native widgets? I 
wonder...

>
>
>>>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.
>
Yes. I just wanted to make sure that not only Winapi functions, but our 
own abstract function can be implemented alongside and you (or other 
developers) will not object to this practice.
Winapi can (and should) stay, just should be moved behind bit by bit :-)

>
>>>>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.
>
You are right - we will see what to do once we make more progress :-) We 
could also use some crossplatform lib for some of this stuff, like SDL 
for fast graphics, sound and video, Preferably other open source 
projects to combine efforts.

Michal