[Lazarus] More Gtk3 Status

Anthony Walter sysrpl at gmail.com
Fri Jul 15 13:47:11 CEST 2022


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
<https://github.com/sysrpl/Lazarus.Terminal> and video here
<https://cache.getlazarus.org/videos/vte-finished.mp4>) that currently
works under Gtk2. While writing the Gtk2 version I referenced the flat C
API from here
<https://developer-old.gnome.org/vte/unstable/VteTerminal.html> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20220715/8dfc1266/attachment-0001.htm>


More information about the lazarus mailing list