Lazarus Release Candidate 1 of 3.0

[BrunoK]

Post it to the bugtracker?

Is that a joke ?

[Bart]

Post it to the bugtracker?

Is that a joke ?

No.
The idea was to post the solution to the bugtracker (presuming this is in the bugtracker).
I admit I'm too lazy to see wether this already has been done.

Bart

[BrunoK]

No.
The idea was to post the solution to the bugtracker (presuming this is in the bugtracker).
I admit I'm too lazy to see wether this already has been done.

Bart

I mentionned that I'll use it.

But as discussed in the last messages of the thread at the time https://forum.lazarus.freepascal.org/index.php/topic,62011.msg469074.html this looks a bit of a hack since we do not seem to understand why the problem exists in the first place.

My bet is that something is not correct in win32callback.inc in  the handling of WM_ERASEBKGND, but I must confess deep incompetence in the matter.

[valdir.marcos]

https://gitlab.com/freepascal.org/lazarus/lazarus/-/tree/lazarus_3_0_RC1

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

1. The LCL currently supports:
2. Linux/FreeBSD (GTK2, Qt4, Qt5 and Qt6)
3. all flavors of Windows (even WinCE)
4. macOS (Cocoa, Carbon, GTK2, Qt4, Qt5, Qt6)
5.  
6. There is an experimental support for:
7. GTK3
8. Solaris
9.  
10. The LCL still contains code for GTK1, although this target is obsolete.

Is it already time to drop support for Qt4 in following lazarus_4_0?


Is it already time to drop support for GTK1 in following lazarus_4_0?

[valdir.marcos]

https://gitlab.com/freepascal.org/lazarus/lazarus/-/tree/lazarus_3_0_RC1

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

1. The LCL currently supports:
2. Linux/FreeBSD (GTK2, Qt4, Qt5 and Qt6)
3. all flavors of Windows (even WinCE)
4. macOS (Cocoa, Carbon, GTK2, Qt4, Qt5, Qt6)
5.  
6. There is an experimental support for:
7. GTK3
8. Solaris
9.  
10. The LCL still contains code for GTK1, although this target is obsolete.

I tested with fixes_3_0 HEAD, building Lazarus with LCL-QT5 and Anchordocking + Docked Form Editor under Manjaro Linux + KDE.

How to build fixes_3_0 (or lazarus_3_0_RC2, or lazarus_3_0_RC1) using GTK3?

Code: Bash  [Select][+][-]

1. $ # This is to install Lazarus 2.2.6 and FPC 3.2.2 using GTK2
2. $ sudo pacman -Syyu
3. $ sudo pacman -Sy make gtk2 gtk3 fpc fpc-src lazarus lazarus-gtk2
4.  

Code: Bash  [Select][+][-]

1. $ # This is to install Lazarus 3.0.0 RC1 with fixes and FPC 3.2.2
2. $ cd ~
3. $ git clone https://gitlab.com/freepascal.org/lazarus/lazarus.git lazarus
4. $ cd lazarus
5. $ git switch fixes_3_0
6. $ make clean bigide
7. $ ./lazarus &

Code: Bash  [Select][+][-]

1. $ # This is to update Lazarus 3.0.0 RC1 with fixes and FPC 3.2.2
2. $ cd ~/lazarus/
3. $ git pull
4. $ make clean bigide
5. $ ./lazarus &

[valdir.marcos]

Maybe it is time for RC2 soon?
Rebuilding Lazarus installed from RC1 .deb packages does not succeed and it must be fixed for RC2. I don't know if Mattias has looked at it.

Yep. RC2 would be welcome.
Two months has almost passed by since RC 1 was released on July 03, 2023.


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

Lazarus Release Candidate 2 of 2.2.0
https://forum.lazarus.freepascal.org/index.php/topic,57021.0.html

if I may ask, now that there is a release candidate, what's the typical amount of time elapsed between a release candidate and the actual release ?
Thank you and thank you for all the hard work the team has put and is putting into Lazarus.

In the past we were aiming at 4 to 6 weeks.
At the moment we got lots of other stuff going on. So no idea.

Thank you all for the hard work on FPC and Lazarus!

[zeljko]

https://gitlab.com/freepascal.org/lazarus/lazarus/-/tree/lazarus_3_0_RC1

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

1. The LCL currently supports:
2. Linux/FreeBSD (GTK2, Qt4, Qt5 and Qt6)
3. all flavors of Windows (even WinCE)
4. macOS (Cocoa, Carbon, GTK2, Qt4, Qt5, Qt6)
5.  
6. There is an experimental support for:
7. GTK3
8. Solaris
9.  
10. The LCL still contains code for GTK1, although this target is obsolete.

Is it already time to drop support for Qt4 in following lazarus_4_0?


Is it already time to drop support for GTK1 in following lazarus_4_0?

Qt4 won't be dropped since it works without problems and I will maintain it.

[JuhaManninen]

How to build fixes_3_0 (or lazarus_3_0_RC2, or lazarus_3_0_RC1) using GTK3?

You can select the widgetset in Configure "Build Lazarus"... window, but Lazarus built for GTK3 is not usable yet unfortunately. You can try and see yourself.

[valdir.marcos]

How to build fixes_3_0 (or lazarus_3_0_RC2, or lazarus_3_0_RC1) using GTK3?

You can select the widgetset in Configure "Build Lazarus"... window, but Lazarus built for GTK3 is not usable yet unfortunately. You can try and see yourself.

You're right. Thanks.

Could small contributions on GTK3 be sent directly with commit and pull request (PR) on GitLab?

Or should all and any contributions be sent via patches on GitLab's issues tracker?

[zeljko]

You can send merge requests.

[valdir.marcos]

You can send merge requests.

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?


* PS: My fault. Sorry. As corrected by @JuhaManninen, @Zeljko is not the creator of LCL-GTK2.

[JuhaManninen]

@valdir.marcos, that is not related to Release Candidate 1 of 3.0 at all.
Please start a new thread.

[valdir.marcos]

@valdir.marcos, that is not related to Release Candidate 1 of 3.0 at all.
Please start a new thread.

I am sorry for that.

I have just created the topic below:

LCL GTK3 bindings
https://forum.lazarus.freepascal.org/index.php/topic,64493.0.html

[jamie]

No.
The idea was to post the solution to the bugtracker (presuming this is in the bugtracker).
I admit I'm too lazy to see wether this already has been done.

Bart

I mentionned that I'll use it.

But as discussed in the last messages of the thread at the time https://forum.lazarus.freepascal.org/index.php/topic,62011.msg469074.html this looks a bit of a hack since we do not seem to understand why the problem exists in the first place.

My bet is that something is not correct in win32callback.inc in  the handling of WM_ERASEBKGND, but I must confess deep incompetence in the matter.

 The real fix for that problem is to treat the TGroupBox the way it should be treated. Currently it receives focus, not the child controls but the group box itself.

 Also there are Keyboard events attached to it, it isn't supposed to have this, only the child controls. I don't know what the real intent was, maybe to monitor all keystrokes going to child controls? In any case it does not work
   If you click on an area of the groupbox that has no child control, it gains keyboard focus, it's not supposed to.

  This is a LCL design that is flawed, I am sure it works in other targets and most likely was put there just for other targets, but it serves no purpose in windows other than causing child controls not to get painted at times when the groupbox itself, not the child controls have the focus.

 And yes, suggested fixes was done but never applied

[BrunoK]

The real fix for that problem is to treat the TGroupBox the way it should be treated. Currently it receives focus, not the child controls but the group box itself.

I find normal that a TCustomGoupBox descendent can have an  Enter event via Keyboard / Mouse so it can setup its child controls if the programmer wants to do things.

Also there are Keyboard events attached to it, it isn't supposed to have this, only the child controls. I don't know what the real intent was, maybe to monitor all keystrokes going to child controls? In any case it does not work.

Maybe for TGroupBox. But TRadioGroup and TCheckBox, being created from Items (TStrings) there needs to be a way for the group to have its keys handled, hence the TCustomGroupBox control having the control on the children events.

   If you click on an area of the groupbox that has no child control, it gains keyboard focus, it's not supposed to.

The GroupBox should at least support OnEnter and OnExit and this is dependent on Getting/loosing focus. I'm sure it was the same in Delphi when I used it.

This is a LCL design that is flawed, I am sure it works in other targets and most likely was put there just for other targets, but it serves no purpose in windows other than causing child controls not to get painted at times when the groupbox itself, not the child controls have the focus.

Could you explain / specify how you think it should behave.