LCL GTK3 bindings

[valdir.marcos]

There is another conversation about Lazarus and GTK3 bindings on the topic below:

Lazarus Release Candidate 1 of 3.0
https://forum.lazarus.freepascal.org/index.php/topic,63867.135.html

Can an administrator or a moderator move those GTK3 related posts from there (page 10) to here?

Thanks.

[JuhaManninen]

Below is a quote copied from the "Lazarus Release Candidate 1 of 3.0" thread.
I have admin rights of some level but I don't know how to move single posts between threads. My GUI has a "split thread" button only.

I am still gathering information about GTK3 status in Lazarus before MR.

As a matter of fact, it seems to me that the whole process involving GTK3 in Lazarus should be done from scratch, in a new branch, including create a new gir2pascal tool.

This is a huge task that will take a long time journey to be done and the obvious problem is that nobody wants to lead and become the LCL-GTK3 bindings' maintainer because GTK core developers have a bad reputation of changing API/ABI all the time even after stabilization, and not listening to community requests and complaints, and not solving error tickets created by people outside their bubble...

As any other huge task, the process of making a new GTK3 interface in Lazarus will demand new tools to automatize things such as development, testing and documentation as much as possible and create a new manual for future new contributtors. And even some money here and there...

There will propably be many complaints about why it is taking so long to be done...

And after all that work, there will propably be complaints about replacing the 10-year-old-development "incomplete GTK3 version 1" with the most recent "complete GTK3 version 2" in Lazarus 5.0 or 6.0...

As the creator of LCL-GTK2, LCL-GTK3 version 1, LCL-Qt4, LCL-Qt5 and LCL-Qt6 bindings, what do you think?

You addressed Zeljko with your question. I remember he explained in some forum post or e-mail earlier that the basic design of LCL-GTK3 good. There are 2 levels of class structures to make things more clear.
LCL-Cocoa is somewhat following the design of LCL-GTK3 if I understood right.
They are not like the GTK1/Gtk2 mess. LCL-Gtk2 was modified from LCL-GTK1, initially with IFDEFs but then copied to its own widgetset folder. It has lots of old historical package and was dumped when implementing LCL-GTK3.

BTW, Zeljko is not the creator of LCL-GTK2.
He created the initial version of LCL-GTK3 and earlier he created + maintains LCL-QTx.

My own knowledge about any widgetset code is poor. I have other priorities and areas of interest where I use my limited time and capacity.
I hope Zeljko explains the LCL-GTK3 situation more.
I agree there should be a thorough documentation about how to implement a widgetset. The whole higher level code supporting widgetsets could possibly be improved, too.

[zeljko]

All I can say that there's a lot of talking around what we (developers) have to do, but no one except 2 dozen of us provided some code.
LCL-Gtk3 is there, not in bad shape, but with lot of things to be implemented. So volunteers with patches are welcome.
Also, if someone is interested to create gtk3 again from the ground zero, welcome

[colo]

I started a similar thread a while ago.

Unfortunately, I lack much of the skillset needed to improve the situation of LCL's GTK3 support, but I would happily throw some funds (caveat: I'm just a private individual and not rich, so please don't expect large sums to go around  ) at people investing their expertise and time to make it happen.

[valdir.marcos]

All I can say that there's a lot of talking around what we (developers) have to do, but no one except 2 dozen of us provided some code.

I understand and agree.

LCL-Gtk3 is there, not in bad shape, but with lot of things to be implemented. So volunteers with patches are welcome.
Also, if someone is interested to create gtk3 again from the ground zero, welcome

Thanks for sharing your view-point.

It seems that I am not the only one studying GTK3 and trying to help:

lcl: gtk3: clean up
https://gitlab.com/freepascal.org/lazarus/lazarus/-/commit/f9709f6d59ea837bc0315e22237e9a0ebae9eeae

GTK3: Updated Gtk3 unit generated with new gir2pas version.
https://gitlab.com/freepascal.org/lazarus/lazarus/-/commit/a90922b2f28d77fd4b0cc37fca8bfc492cb69958

GTK3: Updated Gtk3 units generated with new gir2pas version.
https://gitlab.com/freepascal.org/lazarus/lazarus/-/merge_requests/207

[valdir.marcos]

Below is a quote copied from the "Lazarus Release Candidate 1 of 3.0" thread.
I have admin rights of some level but I don't know how to move single posts between threads. My GUI has a "split thread" button only.

I am still gathering information about GTK3 status in Lazarus before MR.

As a matter of fact, it seems to me that the whole process involving GTK3 in Lazarus should be done from scratch, in a new branch, including create a new gir2pascal tool.

This is a huge task that will take a long time journey to be done and the obvious problem is that nobody wants to lead and become the LCL-GTK3 bindings' maintainer because GTK core developers have a bad reputation of changing API/ABI all the time even after stabilization, and not listening to community requests and complaints, and not solving error tickets created by people outside their bubble...

As any other huge task, the process of making a new GTK3 interface in Lazarus will demand new tools to automatize things such as development, testing and documentation as much as possible and create a new manual for future new contributors. And even some money here and there...

There will propably be many complaints about why it is taking so long to be done...

And after all that work, there will propably be complaints about replacing the 10-year-old-development "incomplete GTK3 version 1" with the most recent "complete GTK3 version 2" in Lazarus 5.0 or 6.0...

As the creator of LCL-GTK2, LCL-GTK3 version 1, LCL-Qt4, LCL-Qt5 and LCL-Qt6 bindings, what do you think?

You addressed Zeljko with your question.

Your opinion is also very important to me! Thanks for sharing it.

I remember he explained in some forum post or e-mail earlier that the basic design of LCL-GTK3 good. There are 2 levels of class structures to make things more clear.
LCL-Cocoa is somewhat following the design of LCL-GTK3 if I understood right.
They are not like the GTK1/Gtk2 mess. LCL-Gtk2 was modified from LCL-GTK1, initially with IFDEFs but then copied to its own widgetset folder. It has lots of old historical package and was dumped when implementing LCL-GTK3.

BTW, Zeljko is not the creator of LCL-GTK2.
He created the initial version of LCL-GTK3 and earlier he created + maintains LCL-QTx.

Thank you for correcting me and for providing the correct information.

My own knowledge about any widgetset code is poor.
I have other priorities and areas of interest where I use my limited time and capacity.
I hope Zeljko explains the LCL-GTK3 situation more.

I understand and respect your position.

I agree there should be a thorough documentation about how to implement a widgetset.
The whole higher level code supporting widgetsets could possibly be improved, too.

Thanks.

[valdir.marcos]

I started a similar thread a while ago.

Unfortunately, I lack much of the skillset needed to improve the situation of LCL's GTK3 support, but I would happily throw some funds (caveat: I'm just a private individual and not rich, so please don't expect large sums to go around  ) at people investing their expertise and time to make it happen.

All kinds and levels of help and support are important.

[valdir.marcos]

I also have little free time and making a widget set binding should be a full time job for a team of programmers and not a lone programmer.

For now, I'm just studying the trajectory of the LCL-GTK3.

Initially, my idea was to contribute to your (@zeljko) work in progress, but it's harder to understand and learn from the end to the beginning.

So, I set up a separate environment and started from scratch. Even so, it is an arduous journey:
- at least two of @JuhaManninen's observations are similar to mine;
- I had a hard time finding detailed documentation on how LCL works and how to make a widget set binding for it;
- the more I study the current source code, both from the high-level LCL side and from the GTK bindings[1-3] side, the more I get the impression that there is room for improvement;

Some recent examples:

Code cleanup in gtk widgetsets
https://forum.lazarus.freepascal.org/index.php/topic,63833.0.html

State of the GTK3 bindings and widgetset?
https://forum.lazarus.freepascal.org/index.php/topic,63946.0.html

- I had a hard time finding a background explaining why those decisions were made and why they were valid at that time (between one and three decades ago considering LCL and GTK1, 2 and 3). I discovered something by reading old forum comments, public emails and bug tickets;

There is also enormous pressure regarding GTK3 and GTK4, which is understandable, on the few programmers who work voluntarily on the Lazarus project, but there are few people who understand the difficulties or bother themselves to help by donating source code or money.

Without making any commitments or promises, I am studying and trying to remake the LCL-GTK3 version 2 bindings in my spare time. It's a huge job to fit into a few hours a week.

I hope to contribute with version 1 or make a proposal for version 2 down the road. And there's always the risk that I won't get anywhere due to the lack of free time and the size of the difficulties.

Seeing my own struggles along the way, my current need is to understand the process, whys and source code to improve the LCL documentation on how one could contribute to current widget sets or make a new one from scratch. So I've been asking questions here and there.

As much as possible, I want to use this thread to talk about my journey and ask for help from time to time.

[zeljko]

Keep in mind that gir2pascal provided stuff is pure gtk and it needs to be properly implemented to the lcl. You can use direct way like gtk1 or gtk2 but soon it'll be a huge mess with hundreds of callbacks, duplicated code etc. Better way is to create pascal class inheritance like in gtk3 and inside class methods write gtk calls, just like it is done in all qt ws and cocoa. It is easer to maintain ws in that case.

[valdir.marcos]

Keep in mind that gir2pascal provided stuff is pure gtk and it needs to be properly implemented to the lcl.

You can use direct way like gtk1 or gtk2 but soon it'll be a huge mess with hundreds of callbacks, duplicated code etc.

Better way is to create pascal class inheritance like in gtk3 and inside class methods write gtk calls, just like it is done in all qt ws and cocoa.

It is easer to maintain ws in that case.

Thanks for this information. I understand its importance.

I am still worried about gir2pascal's output and studying and trying some alternatives.

I am still studying LCL and it seems to me that witdget sets should be plugged into Lazarus IDE instead of glued to it (Cohesion and Coupling while software engineering principles) forcing 2GB memory on each rebuilding of the IDE, which is also time-consuming. But I know that Lazarus does not a have a plug-in engine and I understand that it would be another huge task for few core devlopers to implement it.

I also should be using trunk versions of Lazarus (main_3_99 tag now) and FPC (3.3.1 tag since 2018), but I am using Lazarus fixes_3_0 tag instead because of its stability.

When trunk stops compiling, and this happens with a certain frequency and some times for long periods, my studying is also affected and delayed. And, usually, I just have some hours a week to study this subject.

Thanks for your kindness support.

[JuhaManninen]

I am still worried about gir2pascal's output and studying and trying some alternatives.

What exactly worries you about gir2pascal?

I am still studying LCL and it seems to me that witdget sets should be plugged into Lazarus IDE instead of glued to it (Cohesion and Coupling while software engineering principles) forcing 2GB memory on each rebuilding of the IDE, which is also time consuming.

Widgetsets are part of LCL. Lazarus IDE uses LCL just like any other application. No special treatment there.
FPC builds quite fast compared to C++ compilers. I don't see a big problem there.

I also should be using trunk versions of Lazarus (main_3_99 tag now) and FPC (3.3.1 tag since 2018), but I am using Lazarus fixes_3 tag instead because of its stability.
When trunk stops compiling, and this happens with a certain frequency and some times for long periods, my studying is also affected and delayed. And, usually, I just have some hours a week to study this subject.

I use Lazarus trunk with FPC release version 3.2.2. Having also FPC trunk would add useless problems when I am working on Lazarus features.
Compilation errors are rare and they are typically fixed quickly.

[valdir.marcos]

I am still worried about gir2pascal's output and studying and trying some alternatives.

What exactly worries you about gir2pascal?

We're in quicksand here.

I do not want and will not criticize anyone's past work.

I just want to understand the reasons for the decisions made and how things were done to be able to contribute a little.

I'm still studying. And LCL, widget sets, GTK3 and GTK4 are very big, very important and very time-consuming topics to understand.

It's still too early. I only have some impressions, which are not even opinions, much less valid arguments to be defended.

With due respect, I will refrain from going into the merits until I have something useful to say.

I am still studying LCL and it seems to me that witdget sets should be plugged into Lazarus IDE instead of glued to it (Cohesion and Coupling while software engineering principles) forcing 2GB memory on each rebuilding of the IDE, which is also time consuming.

Widgetsets are part of LCL. Lazarus IDE uses LCL just like any other application. No special treatment there.
FPC builds quite fast compared to C++ compilers. I don't see a big problem there.

Thanks for this information. I understand its importance.

I also should be using trunk versions of Lazarus (main_3_99 tag now) and FPC (3.3.1 tag since 2018), but I am using Lazarus fixes_3_0 tag instead because of its stability.
When trunk stops compiling, and this happens with a certain frequency and some times for long periods, my studying is also affected and delayed. And, usually, I just have some hours a week to study this subject.

I use Lazarus trunk with FPC release version 3.2.2.
Having also FPC trunk would add useless problems when I am working on Lazarus features.
Compilation errors are rare and they are typically fixed quickly.

I beg your pardon if I mean anything different from time-consuming is an important matter to me when trying to understand Lazarus IDE source code.

I don't develop neither Lazarus IDE trunk [development version] nor FPC compiler trunk on a daily basis. I just use the end product to work.

It might be only a coincidence that I had some problems with trunk, just like what happened with Josh and Gus earlier today. [messages are below]

Then, I have decided to study with a more smooth environment [fixes_3_0] that is more stable than trunk and have a newer source code than Lazarus last stable [2.2.6], that is a bit old since Lazarus 3.0 is about to be released: I have just chosen a middle solution for me.

I know I'll have to use trunk versions of Lazarus and FPC before sending any pacths, PR, MR or whatever kind of source code contribution when I am ready. I just believe that using trunk versions right now it's not a good option for me.

What happens now is just that GTK3 is a 10-year-old big problem on Lazarus and I would like to give some kid of contribution, if I am able to, to improve that situation.

I am using the latest released version (2.0.2) of Lazarus, not the latest trunk (=beta). I will need a separate installation to test on the latest trunk.

Yes, except that you don't need to install it really. Just get the sources and run "make".
http://wiki.freepascal.org/Getting_Lazarus#Development_version_of_Lazarus
Then start with "./lazarus", or using a separate configuration "./lazarus --pcp=~/.lazarus_trunk" or similar.
For your bug it should make no difference because my latest commit was only a cleanup, but testing trunk is recommended anyway. It is really so easy when you have FPC installed from your distro repos already.
BTW, "trunk" is not beta. It is the development version that changes by every new commit.

You wrote earlier the problem happens only with Lazarus source editor which is SynEdit. Do you use a docked IDE? It had some issues with local menus.

fpcupdeluxe:

tried to install fpc& laz trunk in new folders but get errors
...
any ideas, or does fpc/laz trunk have major issues at the moment[?]

fpcupdeluxe:

Hey @DonAlfredo,

Sorry to pile on, but I can confirm this on Ubuntu 23.04 64b:

...

The 2 highlighted lines ( 22, 24 ) should produce some kind of bearings for Google to help, but alas, that's not the case since they are old entries on this forum and the solutions, I don't apply.

The commits I'm at.

FPC

Code: Text  [Select][+][-]

1. commit 0c3f7bb6645cc2b5122f78fcf12776a1da55ed76 (HEAD -> main, origin/main, origin/HEAD)
2. Author: Michaël Van Canneyt <michael@freepascal.org>
3. Date:   Sat Sep 9 17:07:31 2023 +0200
4.  
5.     * Allow event handlers to modify input

Lazarus

Code: Text  [Select][+][-]

1. commit dbde03d6a31c4d938ddd1ba9643a4d6005e22204 (HEAD -> main, origin/main, origin/HEAD)
2. Author: rich2014 <rich2014.git@outlook.com>
3. Date:   Sat Sep 9 23:16:22 2023 +0800
4.  
5.     Cocoa: Fix #40495: auto language detection on MacOS
6.    
7.     add LANG environment variable from AppleLocale in GUI APP

I'm including my fpc.cfg, if that makes any difference.

Thanking in advance to anyone that can crack this one 

Cheers,
Gus

[JuhaManninen]

Yes, Lazarus trunk + FPC trunk combination is prone to errors.