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


--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Reply via email to