> Denis,
>
> I will attempt the big design flaws I have found so far while wrangling with
> the current Gtk3 widget implementation.
> There are three main layers underpinning cross platform LCL widgetset.
>
> 1) We obviously have the LCL itself that mimics the VCL and creates a cross
> platform component and control library with the same classes and hierarchy
> across multiple platforms. This piece works well enough.
>
> 2) We have underlying native toolkits written in C or C++, or some other
> language, whose functionality is exposed to Free Pascal by a flat C style API
> of imported functions, enumerations, constants, and records. This piece works
> well enough also.
>
> 3) We have a series of pascal WS (widgetset) classes used in conjunction with
> the "RegisterWSComponent(TSomeControl, TWSSomeControl);" that is responsible
> for binding the 1 and 2 layers. The WS classes are responsible for creating
> the actual underlying native toolkit widget or control from layers 2 and
> bridging access to specific properties and methods to layer 1. Okay, this
> works. I would have designed a set of interfaces to bridge this piece
> instead, but we have these WS classes. I'll deal with it.
>
> Now here is the first big problem with the Gtk3 widgetset as implemented.
> Somehow someone decided it would be a neat idea to add a 4th piece just for
> Gtk3. This piece attempts to wedge itself between 2 and 3 by recreating the
> already existing flat C style API from piece 3 as a big series of pascal
> objects that redeclare the Gtk3 API as a series of objects (see TGtk3Widget
> in the file gtk3widgets.pas). Now we have a 4th layer just for Gtk3 that not
> only adds more complexity, but also introduces peculiar behaviors altering
> what someone writing a Gtk3 native widget port needs to know while following
> through with creating a control or component.
>
> For an example of the problem this additional with Gtk3 4th layer introduces,
> consider my attempts to take some Gtk2 widgets I have written and also
> support them in Gtk3 with its extra layer. I recently updated my gtk vte
> (virtual terminal emulator control, code here and video here) that currently
> works under Gtk2. While writing the Gtk2 version I referenced the flat C API
> from here and had little to no problems getting it working. With the Gtk2
> widgetset implementation in Lazarus I was able to just use the Gtk2 documents
> online to see what functions existed related to working with Gtk2 widgets and
> it worked. This is what I expect when working with a native widgetset, that
> is I read the documentation provided by the actual widget to toolkit maker
> (reading documentation at gnome.og).
>
> Now with the current Gtk3 widget implementation tries to introduce a whole
> other extra layer that works differently than the actual Gtk3 documentation
> provides. Not only are the Gtk/Gdk functions I need hidden elsewhere, but
> they work differently in most cases, as decided by whomever is maintaining
> the base Gtk3 widgetset for Lazarus. I DO NOT want to spend my time trying to
> figure out where someone has hidden a Gtk3 widget API inside some class from
> which I am supposed to figure out to inherit in the hopes that the Gtk3
> widgetset maker got right. This whole declaration of the flat Gtk3 C style
> API and putting them into another set of pascal classes that are then
> references by WS classes and then referenced by LCL controls and components
> is just BAD BAD BAD.
>
> It should be KISS. Just make the control handle an actual reference to the
> underlying system toolkit handle, and please DO NOT attempt to recreate
> another object hierarchy (in addition to the WS classes) of each possible
> widget or object type present on a platform or toolkit combination. Stay with
> a straight flat C style API and let me read the actual developers
> documentation instead of forcing me to figure and find errors you created in
> wiring a whole new API re-duplicating their APIs above and beyond and behind
> the LCL.
>
> For reference, in addition the vte example I posted above, I have also been
> wrangling with webkitgtk for Gtk3 also OpenGL under Gtk3 with the same
> problems.
Hi Anthony
While I understand your concerns and they seem clear & perfectly valid, but I
cannot help or influence Lazarus/FPC devs in any way.
If they accept this layer as ok, it's they who support Lazarus & they decide at
the very end which way GTK3 would go.
I guess it's Mattias Gaertner whom you should talk to. It's the one who
volunteered to develop & support GTK3 stuff right now.
It would be nice to have Mattias join this discussion.
-- Regards,
Denis Golovan
--
_______________________________________________
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
