[Lazarus] Is Lazarus project in a downward spiral?

[Hans-Peter Diettrich]

Graeme Geldenhuys schrieb:

> As far as I understand, there is/was two three goals for the Lazarus project.
> 
> 1) Delphi compatible (we don't know which version though)
> 
> 2) Cross platform
> 
> 3) Native widgets to help the look and feel argument.
> 
> 
> All of the above is possible without emulating the Windows API, so why
> pollute the LCL with such Windows-ism (I don't know a real word for
> this).

Why not? The low-level API is *syntactically* different for every 
platform, but not so much in the (semantical) functionality.

> As I said, I was looking last night at how much work it will be
> to implement LCL-fpGUI widgets. Immediately I see two units named
> fpguiwinapi.inc and fpguiwinapih.inc, and I think to my self - what
> the fuck?? Why does LCL require all other widgetsets to implement the
> API of a single platform? Just look at Qt, GTK2, fpGUI, MSEgui - all
> cross platform widgetsets without the need of re-implementing the
> Windows API, so why does LCL require it. Bad design?

Why invent another API, when this will have to be implemented again for 
*every* platform? You'll end up in the same number of fpXYZapi.inc 
files, regardless of which API you choose or design yourself.


> Then take a look inside the XXXXwinapih.inc and see all the methods
> that must be implemented by each backend widgets. Those methods uses
> Win32 API types like HDC, WHND, HBITMAP, GDIObject, HGDIOBJ, HHOOK
> etc... All those types mean nothing to Qt, GTK1, GTK2, Cocoa, Carbon,
> fpGUI - yet we are expected to somehow make sense of those and
> translate them so something relevant in each of the other non-Windows
> toolkits. Absurd design.

There is nothing Window-ish about windows, handles, bitmaps etc. - every 
platform and widgetset implements the same, possibly with different 
names. IMO it's the same with C "struct" and "class", which translate 
into Record and Object in OPL.


> And this probably contributes to the problems all other widgetset
> maintainers have and the cause of stability problems. Not only do they
> need to know their own widgetset, they need to have intricate
> knowledge of the Windows API before they can implement their widgetset
> backend (even though that backend has nothing to do with Windows). :-(

The Windows API is documented, so that every developer can find all the 
required/related information. An equivalent documentation of a 
generic[1] FPC or LCL API would take years, including fixes of design 
flaws, and the same again for a reference implementation that would 
allow to test and compare the added widgetset-specific implementations.

[1] Did you ever find documentation for the LCL widgetset interface?

DoDi