Re: [Lazarus] More Gtk3 Status

[Anthony Walter via lazarus]

After some research, I found a few more serious issues with Gtk3. I will
not bother filing bugs as the issues seem too ingrained to the
implementation.

Here are some problems:

1) TGtkWidget makes custom drawing an inaccessible private field value that
cannot be set. What this means is that only certain predefined widgets
(with enumerated contents) in Gtk3Widgets.pas are allowed to receive paint
handling events.

2) The CreateWidget virtual method of TGtkWidget is designed to create an
underlying Gtk3 widget instance. But the design makes
brings inheritance problems, as you cannot make use of the inherited
CreateWidget implementation if you want a different widget type. For
example, a TCustomControl backed by a Gtk.DrawingArea.

3) TGtkWidget is defined as having a "property Widget: PGtkWidget".
PGtkWidget is ^TGtkWidget. TGtkWidget is not a TGtkWidget. Ridiculous.

4) There are a reduplication of header file translations, and they are each
incomplete in their own different ways. There is LazGtk3.pas and Gtk3.pas,
LazGdk3.pas and Gdk3, Pango and LazPango1. The latter names in the list are
duplicates to the lclgtk3 widgetset and are incomplete and different from
the former named units.

5) Colors are not being handled correctly with the Gtk3 implementation. I
don't know how many I have found where clWindowText is not being correctly
translated to a valid RGB (ColorToRGB). For example on my system theme
clWindowText is near white, but with lots of code parts of this Gtk3
implementation it's translated to near black because no RGB translations
are being made.

6) All drawing is being handled by cairo on Gtk3 and drawing on a parent
control (a Form for example) can change the drawing state in a child
control (TPaintBox for example). If I invalidate a form and draw using a
transform, the paintbox drawing is automatically transformed. There are
cairo functions to preserve the state, but they are not being used
correclty in the Gtk3 widgetset implementation.

7) There are lots of other problems.

I completed a couple of tasks related
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] More Gtk3 Status

[Marc Weustink via lazarus]

I don't know if it is the same for GTK 4 buut for GTK 1,2 ,3 the problem was 
that the API isn't stable. It is work in progress. So for every dot version you 
get new functionality. Until they decide it is time for a major release and 
gtkX+1 is born, where gtkX becomes obsolete soon. The moment we (Lazarus) has a 
full WS implementation, the version of GTK is obsolete.

Another problem is/was the way we implemented gtk1, it was our first interface. 
We bolted GTK2 on that code. In the meantime other WS were implemented with a 
better class hierarchy. Which is lucky done for gtk3 too.

Marc

On July 18, 2022 12:03:14 PM GMT+02:00, "Petr Hložek via lazarus" 
 wrote:
>Hi,
>
>I'm sorry, maybe a stupid question. Why trying to implement Gtk3 when
>we have Gtk4? Gtk3 will be outdated very soon and the problem will be
>the same like with Gtk2.
>
>Petr
>
>po 18. 7. 2022 v 11:59 odesílatel zeljko via lazarus
> napsal:
>>
>>
>>
>> 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
>> >  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).
>>
>>
>> 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 

Re: [Lazarus] More Gtk3 Status

[zeljko via lazarus]

On 20. 07. 2022. 01:46, Maxim Ganetsky via lazarus wrote:

19.07.2022 10:50, zeljko via lazarus пишет:



On 18. 07. 2022. 17:53, Alexey Torgashin via lazarus wrote:


Zeljko, currently gtk3 WS is not able to run my text editor app. 
Various visual bugs in the main form. I will be happy to pay you 
(initial author) 200$ if you fix the gtk3 for my editor (others will 
benefit too in theory).


Sorry, but I don't have enough spare time to play with gtk3, but even 
if I fix it I don't need money for that work, better give it to 
lazarus project. Can you point to specific issues ?


E. g.

https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39335

It even has a patch attached, which needs a review.



That patch isn't ok. Just drop simple TStringGrid with ScrollBars = 
sbAutoBoth and increase row count so it needs scrollbar: it is not 
visible even if you have thousands of rows, but scrolling looks ok, 
better than it's now.


zeljko
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] More Gtk3 Status

[Maxim Ganetsky via lazarus]

19.07.2022 10:50, zeljko via lazarus пишет:



On 18. 07. 2022. 17:53, Alexey Torgashin via lazarus wrote:


Zeljko, currently gtk3 WS is not able to run my text editor app. 
Various visual bugs in the main form. I will be happy to pay you 
(initial author) 200$ if you fix the gtk3 for my editor (others will 
benefit too in theory).


Sorry, but I don't have enough spare time to play with gtk3, but even if 
I fix it I don't need money for that work, better give it to lazarus 
project. Can you point to specific issues ?


E. g.

https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39335

It even has a patch attached, which needs a review.

--
Best regards,
 Maxim Ganetsky  mailto:gan...@narod.ru

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] More Gtk3 Status

[zeljko via lazarus]

On 18. 07. 2022. 17:53, Alexey Torgashin via lazarus wrote:


Zeljko, currently gtk3 WS is not able to run my text editor app. Various 
visual bugs in the main form. I will be happy to pay you (initial 
author) 200$ if you fix the gtk3 for my editor (others will benefit too 
in theory).


Sorry, but I don't have enough spare time to play with gtk3, but even if 
I fix it I don't need money for that work, better give it to lazarus 
project. Can you point to specific issues ?


zeljko
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] More Gtk3 Status

[Alexey Torgashin via lazarus]

Zeljko, currently gtk3 WS is not able to run my text editor app. Various 
visual bugs in the main form. I will be happy to pay you (initial 
author) 200$ if you fix the gtk3 for my editor (others will benefit too 
in theory).


Alexey
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] More Gtk3 Status

[Marco van de Voort via lazarus]

On 18-7-2022 12:03, Petr Hložek via lazarus wrote:

I'm sorry, maybe a stupid question. Why trying to implement Gtk3 when
we have Gtk4? Gtk3 will be outdated very soon and the problem will be
the same like with Gtk2.


It is not known how much it even matters for the subset that LCL uses. 
Interested people could simply try to get the GTK3 port working with 
GTK4, and evaluate the differences.



--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] More Gtk3 Status

[Petr Hložek via lazarus]

Hi,

I'm sorry, maybe a stupid question. Why trying to implement Gtk3 when
we have Gtk4? Gtk3 will be outdated very soon and the problem will be
the same like with Gtk2.

Petr

po 18. 7. 2022 v 11:59 odesílatel zeljko via lazarus
 napsal:
>
>
>
> 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
> >  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).
>
>
> 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 

Re: [Lazarus] More Gtk3 Status

[zeljko via lazarus]

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



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 

Re: [Lazarus] More Gtk3 Status

[Anthony Walter via lazarus]

Kostas,

We already have an object oriented layer to interact with controls. That
layer is the LCL. What you are saying is it makes sense for each widgetset
to create their own separate and independent class hierarchy, or to use
TWidgetInfo, or have something akin to:

  LCL-> WSClasses -> TSomePlatformWidgets (ie TGtk3Widget class and
derivitatives) -> Flat C API

What would make more sense to me would be:

  LCL Object -> IWidget -> Flat C API

Where any control would need to fill implement the requirements of IWidget
to be complete. In this way we could have a contract between the LCL and
what is expected of a control (IWidget), a button (IButton), a listbox
(IListBox), a page control (IPageControl), and so on.

You might ask how does this fix anything? Well first it nails down three
layers instead of four of five. Second, it creates a contact between the
LCL and someone writing the part to go between the LCL and flat C APIs.
Third, it provides a consistent model for  ANYONE wanting to implement a
widgetset, thus making it MUCH easier for people to understand what is
going on. Forth, implementors can look at other widgetsets to understand
how to create a new or fix a malfunctioning part of the widgetset they are
working on.

Again, I would support the idea of using Handles on platform specific
objects, like a Canvas (DC on Windows, CairoRed of gtk3), a WinControl
(HWND on Windows, PGtkObject on gtk2/Gtk3)

IN ADDITION TO

A well described non reference counted interface model for platform
specific objects (IWidget, ICanvas, IButton, IListBox) which the LCL would
depend on to automatically take care of the platform and widget specific
glue.

uses
  { This unit would defines the contract between the LCL and all Widgetset
be defining all relevant
  interfaces  that must be implemented to make a LCL widgetset }
  Widgets,
...
  ;

type
  TWinControl = class(TControl, IWidget)
  private
FWidget: IWidget;
  protected
property Widget: IWidget read FWidget  implements IWidget;

  end;

...

  TCustomListBox = class(TWinControl, IListBox)
  private
function GetListBox: IListBox;
  protected
property ListBox: IListBox read GetListBox implements IListBox;

  end;

...

function TCustomListBox.GetListBox: IListBox;
begin
  Result := Widget as IListBox;
end;
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] More Gtk3 Status

[Kostas Michalopoulos via lazarus]

On 7/15/22 14:47, Anthony Walter via lazarus wrote:

Denis,

I will attempt the big design flaws [...]
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 isn't a flaw, the approach the Gtk3 backend has makes sense if you 
consider that it is trying to avoid all the special case functionality 
for what essentially mimicing the Win32 API in an increasingly (in every 
major version) weird and "non-Win32-like" API.


In a way the Gtk1 and Gtk2 widgetsets do it too but if anything they do 
it in a messier way because for anything non-trivial they allocate a 
separate TWidgetInfo object (a record) that they map between the 
Gtk1/Gtk base widget and the LCL functionality/data that needs to 
emulate the Win32 behavior all the time when that data is needed with 
the source code being littered with calls like 
"GetOrCreateWidgetInfo(handle)".


The Gtk3 widgetset instead of doing that uses the OOP functionality that 
Free Pascal had for decades now :-P to avoid doing that runtime mapping 
and put widget-specific functionality in its own class. Otherwise that 
functionality would need to be spread all over the place - especially 
for calls that assume that a call with HWND would apply to all widgets 
the same way.


Also about that "just for Gtk3", in fact it isn't just the Gtk3 backend 
that takes the OOP approach with a custom class per control - from a 
quick look, the Qt, Qt5, FPGUI, Carbon and MUI widgetsets take that 
approach too.


Just make the control handle an actual reference to 
the underlying system toolkit handle, and please DO NOT attempt to 
recreate another object hierarchy
While it can be a minor surprise, in practice you are already dealing 
with widgetset-specific functionality anyway and you should always keep 
the widgetset itself "in the loop" - meaning that even if you try to 
bypass it, you still need to know what the widgetset does. And again, if 
anything, the Gtk3 approach still seems better because control has its 
own class for the underlying widgets which makes it easier to find what 
is going on.


Kostas
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] More Gtk3 Status

[denisgolovan via lazarus]

> 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

Re: [Lazarus] More Gtk3 Status

[Anthony Walter via lazarus]

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.
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] More Gtk3 Status

[denisgolovan via lazarus]

> Respectfully, I believe the current underlying implementation of Gtk3 is 
> fundamentally a bad design making it unnecessarily difficult to work with. I 
> do not see it being completed and see its poor design as a large part of the 
> reason it has been languishing for so long.

Could you be more specific about "current underlying implementation of Gtk3"?
Do you mean current in-master or the one Michael just publish at foundation 
site?

-- Regards,
Denis Golovan
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] More Gtk3 Status

[Anthony Walter via lazarus]

Respectfully, I believe the current underlying implementation of Gtk3 is
fundamentally a bad design making it unnecessarily difficult to work with.
I do not see it being completed and see its poor design as a large part of
the reason it has been languishing for so long.
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] More Gtk3 Status

[denisgolovan via lazarus]

> I see I forgot to set the page's visibility in the CMS :/
> 
> I did so now.
> 
> Michael.


Thanks, Michael. Now, next step - how can I donate to this specific project?
The only thing I about specific project donation is following: 

=
 At a later stage, we'll set up per-project funding, so you can donate directly 
for the implementation of a particular project you would like to see realized.
=

... I think I saw that note couple years ago, but somehow I managed to donate 
something to specific project.
Unfortunately, I cannot remember how. Could you direct me? Or perhaps state 
this information at site itself?

-- Regards,
Denis Golovan
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] More Gtk3 Status

[Michael Van Canneyt via lazarus]

On Fri, 15 Jul 2022, denisgolovan via lazarus wrote:


Hi Antony & all

Personally I am interested in complete Gtk3 widgetset in Lazarus.
Unfortunately, I can only donate some funds to make it happen. Of course, 
financial help is not the complete solution, but it might help.

Perhaps it's possible to make a separate project at 
https://foundation.freepascal.org/ to collect funds for volunteer(s) for that 
specific purpose.


There already is an ongoing project since 2020 to complete the Gtk3 widgetset ?
Mattias Gaertner looked into this, if my memory serves me well he made an
inventory of the work it would take to bring the Gtk 3 widgetset up-to-date.

I see I forgot to set the page's visibility in the CMS :/

I did so now.

Michael.

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] More Gtk3 Status

[denisgolovan via lazarus]

Hi Antony & all

Personally I am interested in complete Gtk3 widgetset in Lazarus.
Unfortunately, I can only donate some funds to make it happen. Of course, 
financial help is not the complete solution, but it might help.

Perhaps it's possible to make a separate project at 
https://foundation.freepascal.org/ to collect funds for volunteer(s) for that 
specific purpose.

-- Regards,
Denis Golovan
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus