Re: [Lazarus] More Gtk3 Status

2022-07-15 Thread 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

2022-07-15 Thread 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

2022-07-15 Thread 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

2022-07-15 Thread 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

2022-07-15 Thread 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

2022-07-15 Thread 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

2022-07-15 Thread 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

2022-07-15 Thread 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

2022-07-15 Thread 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


[Lazarus] More Gtk3 Status

2022-07-15 Thread Anthony Walter via lazarus
Last year in September 2021 I wrote this list asking about the status of
the Gtk3 widgetset implementation for Lazarus. The consensus at the time
seemed to indicate that the package was still incomplete and had no
maintainer.

Over the past few days, I have been attempting to add Gtk3 widgetset
support to a few upcoming library projects I will soon release. As
someone with a lot of experience in the areas of general programming,
object pascal programming, code library design, and importantly the inner
workings of the Lazarus WS (widgetset) abstraction layers for a few
different backends, I have this to say.

The design of the Gtk3 widgetset backend for Lazarus is fundamentally a bad
design and unnecessarily difficult to work with.

I can provide specifics about all the problems I see with it in a follow up
message if anyone cares to know more, but I am more interested and
motivated to get an answer to a burning question that I hope someone can
answer.

My question is: After 11 years of the Gtk3 release by the Gnome Foundation,
and the unmaintained status of Gtk2 by the same foundation, when are we
within the Lazarus community going to be comfortable going seeing something
someone has started, recognize it as a fundamentally bad design, and
officially delete it, thereby allowing someone else to start fresh perhaps
steering clear of the problems inherited in a prior bad design attempt?

I know I will hear people responding to my question with the statement that
I could do this if it's something I care about. That is, I could start
writing what might consider a proper design of the Gtk3 widgetset for
Lazarus.

To those people, I would say I have a lot of other projects and problems
IRL I am working on at the the moment and don't have the time to start yet
another endeavor as big as redesigning and rewriting the Gtk3 widgetset for
Lazarus. Sure I can provide a lot of valuable insight as to what is wrong
with the current attempt, but don't have the time (my actual health is
failing IRL), but it would be foolish for me to try to take over the Gtk3
widgetset at this point.

In brief, if anyone out there cares about helping Lazarus and bringing its
support for the Linux desktop more up to date with its current underlying
toolkit options, I would offer them both encouragement and some guidance as
to both what to avoid and what to do that is good.

I have a whole bunch of web browser
 related
source code for Lazarus Gtk3 that I have been sitting on, waiting to
publish when Gtk3 support in Lazarus was a bit more mature. I also have a new
OpenGL toolkit  (an example of the source
code interface is here
) I want
to release with Gtk3 support on Lazarus. I'd like to be able to release
this stuff and a lot more before I die.
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus