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

[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 a

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