[Lazarus] More Gtk3 Status

[zeljko]

On 15. 07. 2022. 13:47, Anthony Walter via lazarus wrote:
> 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.


I've commited gtk3 skeleton and basic controls + some winapi functions 
(AFAIR it was 2012 or even 2013). Everything is based on 
qt/qt5/carbon/cocoa philosophy already inside LCL. At that time I've 
maintained gtk2 and it's not so pleasant for maintainer (maybe for you 
as programmer of your apps, but not lazarus lcl-ws maintainer) so my 
decision was to  encapsulate gtk3 to pascal objects, and if someone ask 
me to introduce gtk4 I'll do it in same way. Why ? Easy maintaining.
Also, after I commited gtk3 there were none or just few commiters to the 
gtk3 ws (I could not continue with gtk3 ws because of lacking spare time).

> 
> 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).


You're mixing apples & oranges (LCL vs your application). They're 
different in many ways. Just simple example is event filters and event 
triggering at the right time - eg TListView.OnSelectItem ... 
mousedown->onselectitem->mouseup (order isn't important here, but point 
is that such order should be same on all platforms, and ppl are filling 
bugs about it, so maintainer should fix that if possible).


> 
> 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.

Seen a lot of ppl who give smart advices to lazarus/fpc developers in 
last 15 yrs that I'm commited to lazarus, but rare or none provided any 
code for lazarus.

zeljko