Debian removes FPC/Lazarus lazarus / 32-Linux ---------------------------------------------------------------------- dbannon · 2026-02-06 03:52 Folks, as some of you already know, Debian has removed FPC/Lazarus from its Forky (ie unstable) repo. This is because they are dropping support for gtk2 and both FPC and Lazarus (appear) to depend on the much out of date gtk2 ! Why is this important ? Firstly, a large number of Linux Distros are based on Debian. And some that are not based on Debian still get source packages from there. Almost all distros are in the process of dropping gtk2 anyway. This will be see by all Linux community. Its very bad 'optics' for FPC/Lazarus if Debian drops FPC/Lazarus (and all the apps that depend on FPC/Lazarus). Whats the Issue ? Its obvious how Lazarus depends on GTK2, you may well say, "just use Qt5 or Qt6" but its not that easy. The problem is that FPC also depends on gtk2 on Linux. FPC has a package, eg  lib/fpc/3.2.2/units/x86_64-linux/gtk2/ in a binary install. That provides a number of ppu used, for example by Lazarus. Debian binaries are generated from Debian Source Packages and, presumably, gtk2 is necessary for that generating. The easy solution of removing that package packages/gtk2 from FPC would make FPC acceptable to Debian (I think) but it will break Lazarus. Obviously, lazarus-gtk2 will break (who cares ?) but  so too does, for example, a Lazarus-Qt6 built with bigide. Apparently, all Linux Lazarus installs use the FPC "gtk2 package" files to provide - CairoCanvas Glade glib2 Pango .... Without which not too many Lazarus applications, Qt5 or Qt6 will run. Clearly, the answer is to have a new Lazarus package containing the (non-gtk2) units from FPC's gtk2 package. That does introduce some rather messy transition issues. Especially if we cannot have a FPC release ! My ideal solution might be to have a "Linux Only Release", based on FPC324rc1, get that back into Debian and then, with the next release of Lazarus, provide the necessary files as part of LCL. Thoughts ? Davo ---------------------------------------------------------------------- marcov · 2026-02-06 09:49 Quote from: dbannon on February 06, 2026, 04:52:29 amFPC has a package, eg  lib/fpc/3.2.2/units/x86_64-linux/gtk2/ in a binary install. That provides a number of ppu used, for example by Lazarus. Debian binaries are generated from Debian Source Packages and, presumably, gtk2 is necessary for that generating. There is no build depends (as we couldn't do anything with C code anyways). Debian just insists on adding dependencies for all headers in the package. So it is a problem created by Debian. But since Debian has not really a reputation for being flexible, that probably means that the debian maintainers have to split the package again just like it was 10-15 years ago. Or they simply don't install the GTK2 headers, moving only those to a separate package.  Well, packaging things is what packagers do.  Anyway, that is an Debian internal problem. QuoteThe easy solution of removing that package packages/gtk2 from FPC would make FPC acceptable to Debian (I think) but it will break Lazarus. 1. The easiest solution is if Debian simply made an exception and didn't add that dependency by default. FPC is not going to mutilate its build system for Debian's rigidity. 2. Afaik Lazarus has its own headers. Modified: typo debian->lazarus that has own headers ---------------------------------------------------------------------- Zvoni · 2026-02-06 10:42 Quote from: marcov on February 06, 2026, 10:49:00 am1. The easiest solution is if Debian simply made an exception and didn't that dependency by default. FPC is not going to mutilate its build system for Debian's rigidity. Or we do it like the Gambas-Boys and offer our own Repository (or like so many others), outside of Debian's control https://gambaswiki.org/wiki/doc/packages?nh&l=en#t5 ---------------------------------------------------------------------- Fred vS · 2026-02-06 10:57 Quote from: dbannon on February 06, 2026, 04:52:29 amThe problem is that FPC also depends on gtk2 on Linux. Hello Davo. Hum ??? (MSEgui and  fpGUI use FPC without gtk2 or others on Linux). ---------------------------------------------------------------------- dbannon · 2026-02-06 11:24 Quote from: marcov on February 06, 2026, 10:49:00 amThere is no build depends (as we couldn't do anything with C code anyways). Debian just insists on adding dependencies for all headers in the package. So it is a problem created by Debian. No Marcov, sorry. there is a gtk2 package in FPC. Its used, eg, by Lazarus. As I just explained elsewhere, the .ppu and .o files in that package have to be generated on a machine that has gtk2 installed. That package exists in the 'official' FPC packages on Source Forge, its not a Debian invention. Quote from: marcovBut since Debian has not really a reputation for being flexible, Indeed they are not flexible. They maintain over 120,000 packages, would you expect them to be flexible ? Quote from: marcov  1. The easiest solution is if Debian simply made an exception and didn't add that dependency by default. FPC is not going to mutilate its build system for Debian's rigidity. See above. 120k packages ? Quote from: marcov Afaik Lazarus has its own headers. I have hidden that FPCgtk2 directory and found that all my test applications, running Qt5 or Qt6 will no longer build. That directory contains files like - Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i dbannon@dell:~$ ls -l ~/bin/FPC/fpc-3.2.3/lib/x86_64- linux/gtk2/*.ppuatk.ppugdk2pixbuf.ppugdk2.ppugdk2x.ppugdkglext.ppuglib 2.ppugtk2ext.ppugtk2.ppugtkglext.ppulibglade2.ppupangocairo.ppupango.p pu Yep, they can be and should be moved (only the non-gtk2 ones, drop the gtk2). Thats my suggestion above. But messy transition problem. And its most certainly not just a packaging issue.  I have seen little to indicate that the Debian people will undertake anything like that. The question I keep asking myself is why on earth do we have these files managed in FPC ?  They clearly belong in LCL. But interesting, there are also gtk1 files there  And of course, Lazarus is an issue. We ship gtk2 lazarus from source forge. Won't be too many platforms that will run on soon. Davo ---------------------------------------------------------------------- dbannon · 2026-02-06 12:12 Quote from: Fred vS on February 06, 2026, 11:57:35 amHum ??? (MSEgui and  fpGUI use FPC without gtk2 or others on Linux). OK Fred, so no "fpc-3.2.3/lib/x86_64-linux/gtk2" or, in the SRC dir, SRC/fpc-3.2.3/packages/gtk2 ?  Do a find on, eg pangocairo.ppu for me please. It appears in all my FPC trees but not Lazarus. Probably been moved, very sensibly ! (Hmm, interesting, there does seem to be things pangocairo.ppu and cairocanvas.ppu in Lazarus, just my test project cannot find them. Will hav to wait until tomorrow ..... Davo ---------------------------------------------------------------------- cdbc · 2026-02-06 12:20 Hi @Davo: Here's the output from 'ldd' on a small fpGUI test-app:Code: Bash  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i bc@red hello-fpgui$ ldd hello-fpgui         linux-vdso.so.1 (0x00007ffe4c9dd000)        libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007f6e970f8000)        libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007f6e970e4000)        libXft.so.2 => /usr/lib64/libXft.so.2 (0x00007f6e970ca000)        libc.so.6 => /lib64/libc.so.6 (0x00007f6e96edc000)        libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007f6e96eb4000)        libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007f6e96e63000)        libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007f6e96da1000)      libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x00007f6e96d95000)        /lib64/ld-linux-x86-64.so.2 (0x00007f6e97262000)        libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007f6e96d90000)        libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00007f6e96d88000)        libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00007f6e96c27000)        libz.so.1 => /usr/lib64/libz.so.1 (0x00007f6e96bf8000)        libbz2.so.1 => /usr/lib64/libbz2.so.1 (0x00007f6e96be5000)        libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007f6e96b87000)        libharfbuzz.so.0 => /usr/lib64/libharfbuzz.so.0 (0x00007f6e96a2f000)        libbrotlidec.so.1 => /usr/lib64/libbrotlidec.so.1 (0x00007f6e96a21000)        liblzma.so.5 => /usr/lib64/liblzma.so.5 (0x00007f6e969dd000)        libm.so.6 => /lib64/libm.so.6 (0x00007f6e968e8000)        libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007f6e9675e000)        libgraphite2.so.3 => /usr/lib64/libgraphite2.so.3 (0x00007f6e96400000)        libbrotlicommon.so.1 => /usr/lib64/libbrotlicommon.so.1 (0x00007f6e9673b000)        libpcre2-8.so.0 => /usr/lib64/libpcre2-8.so.0 (0x00007f6e9668a000)bc@red hello-fpgui$  This app is compiled with 'fpGUI-1.5.0' and FPC 3.2.2 and I can't see anything GTKx related...? Regards Benny ---------------------------------------------------------------------- Fred vS · 2026-02-06 12:20 Quote from: dbannon on February 06, 2026, 01:12:39 pmQuote from: Fred vS on February 06, 2026, 11:57:35 amHum ??? (MSEgui and  fpGUI use FPC without gtk2 or others on Linux). OK Fred, so no "fpc-3.2.3/lib/x86_64-linux/gtk2" or, in the SRC dir, SRC/fpc-3.2.3/packages/gtk2 ?  Do a find on, eg pangocairo.ppu for me please. It appears in all my FPC trees but not Lazarus. Probably been moved, very sensibly ! (Hmm, interesting, there does seem to be things pangocairo.ppu and cairocanvas.ppu in Lazarus, just my test project cannot find them. Will hav to wait until tomorrow ..... Davo Not sure I understand. Do you mean it's impossible to compile FPC without having GTK2 installed? I agree that I've always compiled FPC on machines where GTK2 is installed. I'll try compiling it on an OpenBox machine without GTK2 (but I remember doing it before and FPC compiled fine). Compiling LCL (Lazarus) is a different story. ---------------------------------------------------------------------- Fred vS · 2026-02-06 12:32 Quote from: cdbc on February 06, 2026, 01:20:15 pm@Davo: Here's the output from 'ldd' on a small fpGUI test-app: ... And here the output from 'ldd' on a big MSEgui app (MSEide): Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i  $ ldd mseide        linux-vdso.so.1 (0x00007ffe9c135000)        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x0000725c19fe4000)        libdl.so.2 => /lib/x86_64-linux- gnu/libdl.so.2 (0x0000725c19fdf000)        libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x0000725c19ea2000)        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x0000725c19e9d000)      libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x0000725c19c00000)        libxcb.so.1 => /usr/local/lib/libxcb.so.1 (0x0000725c19e70000)      /lib64/ld-linux-x86-64.so.2 (0x0000725c1a00c000)        libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x0000725c19e6a000)        libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x0000725c19e62000)        libbsd.so.0 => /lib/x86_64-linux- gnu/libbsd.so.0 (0x0000725c19e4c000)        libmd.so.0 => /lib/x86_64-linux-gnu/libmd.so.0 (0x0000725c19e3d000) ---------------------------------------------------------------------- robert rozee · 2026-02-06 12:36 hi Davo and Marcov,     can i please ask a couple of questions for clarification: 1. if i build a GUI application (today) using Lazarus that targets qt5, will the resulting binary run on linux systems that do NOT have gtk2 (or any other GTK variant) installed? 2. assuming that all the 'offending' bits and pieces were moved from the FPC package to the Lazarus package, would the Debian developers then be happy with FPC? 3. similar questions, but wrt qt5 (or any other qt variant): are there qt bits contained within the FPC package? and could they similarly be moved to the Lazarus package? 4. once the FPC package has been rendered 'GTK and qt free' (and indeed free of any other widgetset dependencies), would it then be possible to create a Lazarus package that: contained NO binary executables or object files;from which FPC alone could rebuild all the binaries and object files necessary to run and use the Lazarus IDE and thence from which arbitrary Lazarus/FPC GUI applications could be built? it just seems to me that provided... A. the FPC package were made widgetset-free, and, B. the Lazarus package being distributed contained JUST source code, ... then the Debian folks would have nothing to complain about. the end user would then just need to: 1. install FPC (containing the already built FPC compiler), 2. install the Lazarus source code package, 3. run a script that builds the Lazarus IDE, library object files, etc. both installs (1. and 2.) could be from the Debian repositories, and both packages would be 'clean'; the "build script" from 3. would generate binaries and object files that depended solely upon existing libraries already installed on the local machine. with the resulting Lazarus IDE and object files having dependencies ONLY on widgetset(s) actually present on the system, this would be far cleaner than the present approach of distributing object files that may have dependencies not fulfillable on the system on which FPC and Lazarus have been installed. cheers, rob   :-) ---------------------------------------------------------------------- marcov · 2026-02-06 12:57 Quote from: dbannon on February 06, 2026, 12:24:22 pmQuote from: marcov on February 06, 2026, 10:49:00 amThere is no build depends (as we couldn't do anything with C code anyways). Debian just insists on adding dependencies for all headers in the package. So it is a problem created by Debian. No Marcov, sorry. there is a gtk2 package in FPC. Its used, eg, by Lazarus. Indeed. Lazarus does use them nowadays, that must have changed. Maybe with the introduction of boolean32. QuoteAs I just explained elsewhere, the .ppu and .o files in that package have to be generated on a machine that has gtk2 installed. That package exists in the 'official' FPC packages on Source Forge, its not a Debian invention. Not that I know, and I routinely compile FPC on headless systems. What error do you get?  Maybe you need it to link, but not the build the .ppu/.o's. Quote Quote from: marcovBut since Debian has not really a reputation for being flexible, Indeed they are not flexible. They maintain over 120,000 packages, would you expect them to be flexible ? Yes.  99.9% are the same configure/make cycle, but FPC is in the other category. QuoteQuote from: marcov  1. The easiest solution is if Debian simply made an exception and didn't add that dependency by default. FPC is not going to mutilate its build system for Debian's rigidity. See above. 120k packages ? Doesn't matter. QuoteI have hidden that FPCgtk2 directory and found that all my test applications, running Qt5 or Qt6 will no longer build. That directory contains files like - That is strange. What error do you get ? Maybe something (print related) using Cairo? QuoteYep, they can be and should be moved (only the non-gtk2 ones, drop the gtk2). Thats my suggestion above. But messy transition problem. And its most certainly not just a packaging issue.  I have seen little to indicate that the Debian people will undertake anything like that. No, they shouldn't. We still support GTK2 for non lazarus applications for distributions that didn't remove GTK2. QuoteThe question I keep asking myself is why on earth do we have these files managed in FPC ?  They clearly belong in LCL. But interesting, there are also gtk1 files there  Non Lazarus obviously.  QuoteAnd of course, Lazarus is an issue. We ship gtk2 lazarus from source forge. Won't be too many platforms that will run on soon. Debian maintainers can build whatever backend they want. They don't need permission from Lazarus for that. ---------------------------------------------------------------------- marcov · 2026-02-06 12:58 Quote from: robert rozee on February 06, 2026, 01:36:02 pmit just seems to me that provided... A. the FPC package were made widgetset-free, and, B. the Lazarus package being distributed contained JUST source code, ... then the Debian folks would have nothing to complain about. or (C) Debian makes an exception on adding the dependency, and everything is fixed without big rearrangements. I vote (C) :-) ---------------------------------------------------------------------- Zvoni · 2026-02-06 13:34 Quote from: marcov on February 06, 2026, 01:58:59 pmor (C) Debian makes an exception on adding the dependency, and everything is fixed without big rearrangements. I vote (C) :-) or (D) offer our own Repo, and package to your hearts content incl. resolving dependencies. I vote (D) ---------------------------------------------------------------------- robert rozee · 2026-02-06 13:36 Quote from: marcov on February 06, 2026, 01:58:59 pmQuote from: robert rozee on February 06, 2026, 01:36:02 pmit just seems to me that provided... A. the FPC package were made widgetset-free, and, B. the Lazarus package being distributed contained JUST source code, ... then the Debian folks would have nothing to complain about. or (C) Debian makes an exception on adding the dependency, and everything is fixed without big rearrangements. I vote (C) :-) as we have no control over the Debian folks, and is seems certain they will not make any exceptions, it does not matter how anyone votes. they (Debian) will not make an exception, and we can all 'vote' until we go blue in the face. cheers, rob   :-) ---------------------------------------------------------------------- ccrause · 2026-02-06 13:41 Quote from: Fred vS on February 06, 2026, 01:20:38 pmNot sure I understand. Do you mean it's impossible to compile FPC without having GTK2 installed? No, the compiler binary itself does not link to a graphics library. It appears to be a secondary dependency problem: FPC provides a GTK2 package that can be used to link against GTK2 libraries.  A user could then use the FPC provided package to create a program that calls GTK2 functions, which would then require the GTK2 library to be present when linking the final executable. ---------------------------------------------------------------------- marcov · 2026-02-06 13:53 Quote from: robert rozee on February 06, 2026, 02:36:13 pmas we have no control over the Debian folks, and is seems certain they will not make any exceptions, it does not matter how anyone votes. they (Debian) will not make an exception, and we can all 'vote' until we go blue in the face. So neither will we change anything during a minor release cycle, since that would jeopardise stability. Probably it will end up as third party debs as Zvoni seems to suggest. And big change even for main that are is doubtful. So then we are back at the standoff that has been happening for over an year now. But at least the positions are clear to everybody now Keep opening those tickets on the debian site and voting them up till they see the light ---------------------------------------------------------------------- dsiders · 2026-02-06 17:34 Quote from: dbannon on February 06, 2026, 12:24:22 pmThe question I keep asking myself is why on earth do we have these files managed in FPC ?  They clearly belong in LCL. But interesting, there are also gtk1 files there  I would imagine that's a dependency for the text mode IDE provided in FPC.... and that doesn't depend on LCL. ---------------------------------------------------------------------- dbannon · 2026-02-06 23:47 OK, here is what I found. And its definitely not what I expected (but probably what Marcov was trying to tell me all along).  FPC can be built on a system that does NOT have gtk2 installed. That does include the packages/gtk2 units. I built a headless Trixie, added only libc6-dev, vim and make. Installed the sourceforge version of FPC322 from Lazarus repo (needing a deb). Then put fpc324rc1 source in a dir, and ran Code: Bash  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i make cleanmake all The attached image (sorry, large) shows the newly created .ppu and .o files in packages/gtk2 and it shows there is no sign of gtk2 on the system. Note : doing this experiment using using the Debian Repo fpc322 is pointless, it installs gtk2 as a dependency. So, this negates my argument that 'we' need restructure fpc and Lazarus, it really is problem introduced by Debian adding gtk2 as a [ build | runtime ] dependency. (We still have a problem with Lazarus, I will investigate further but its clear that by shipping gtk2 Lazarus binaries from SourceForge we send the message that its a gtk2 app.) Davo ---------------------------------------------------------------------- ccrause · 2026-02-07 06:13 I did not follow the original discussions prior to this thread, here are some relevant links for interest (I noticed a lot of the same things are being repeated in this discussion): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967348 https://gitlab.com/freepascal.org/fpc/source/-/issues/39989 One comment by Abou is that fpc itself does not depend on GTK2 and users of the GTK2 fpc package will only require the GTK2 libraries at link time, so there is no need to mark fpc as dependent on the GTK package. The GTK2 package shipped with fpc is no different in its dependencies compared to other wrapper packages such as dbus, libpipewire or libusb, all of which also statically links to external libraries.  None of the other fpc packages are marked as required dependencies on external libraries, so why is the external dependency on GTK2 a required dependency? The Debian suggestion of replacing the GTK2 unit with GTK3 is missing the point. Even if fpc shipped with a GTK3 package, for legacy reasons the GTK2 package should still be provided for those fpc users currently using it. ---------------------------------------------------------------------- dbannon · 2026-02-07 07:35 Ah, I had not spotted that Abou stated gtk2 is not necessary. I was a but worried that he was not involved, he does much of the packaging and is usually pretty active. More power to his strong right arm ! Anyway, I have posted a summary of my suggestion - https://alioth-lists.debian.net/pipermail/pkg-pascal-devel/Week-of- Mon-20260202/006145.html Davo PS an amusing aside : gtk1 is also present there in packages, good luck with getting it going. And, yes, building the compiler does generate the necssary binary files ! ---------------------------------------------------------------------- Thaddy · 2026-02-07 07:43 @dbannon It is not only gtk1/2, but also X itself that is endangered in the near future. After all the trend is towards Wayland as compositor. This is not yet urgent but is only a couple of releases away. All these go together: X, Wayland, GTK < 3. ---------------------------------------------------------------------- zeljko · 2026-02-07 08:19 Qt6 is all we have for wayland, and that can work without xlib deps (of course, at some point must remove complete x11 deps from lcl qt6). I know that many ppl dislike qt because of licensing and because of C bindings in the middle, but that is the only way to go atm, qt6 is pretty stable and should be setted as default for next major release. ---------------------------------------------------------------------- cdbc · 2026-02-07 10:16 Hi @zeljko: Before we push Qt6, could you please have a look at this screenshot attached... I get this when I run apps in the debugger, both 4.4 & trunk/main, as well as when I run the apps from commandline...?!? ...Sometimes it also sports a "Segment Fault" when run without debug- info... Regards Benny ---------------------------------------------------------------------- zeljko · 2026-02-07 11:13 Better open an issue about it and write all details you know about it. ---------------------------------------------------------------------- dbannon · 2026-02-07 11:35 I switched my app from gtk2 to Qt5 in Debian some two years ago. But I still provide downloadable packages. gtk2 downloads outnumber Qt5 or Qt6 about 3:1. I still advise users of newer operating systems to use Qt6. I guess I hope Wayland will fix some of its bugs, particularly the one related to initial window placement, thats a real pain. But Mate DE is not Wayland based yet .... I think Lazarus needs to be shipped with Qt6, maybe GTK3 will improve before Forky is released but Qt6 works now ! Davo ---------------------------------------------------------------------- dsiders · 2026-02-07 16:07 Quote from: dbannon on February 07, 2026, 12:35:31 pmI guess I hope Wayland will fix some of its bugs, particularly the one related to initial window placement, thats a real pain. Wayland does not consider that a bug. They say it's the responsibility of the compositor... and not part of the Wayland design, That's why Wayland is brain-dead. Quote from: dbannon on February 07, 2026, 12:35:31 pmI think Lazarus needs to be shipped with Qt6... Good luck with that. Quote from: dbannon on February 07, 2026, 12:35:31 pm..maybe GTK3 will improve before Forky is released... GTK3 was introduced 15 years ago. If it doesn't work now, it's not likely that it ever will. And even if it did, it's on the verge of becoming legacy too. GTK4 has been out for 5+ years. ---------------------------------------------------------------------- PascalDragon · 2026-02-07 21:12 Quote from: dbannon on February 06, 2026, 04:52:29 amThe easy solution of removing that package packages/gtk2 from FPC would make FPC acceptable to Debian (I think) but it will break Lazarus. FPC also contains a package for GTK1 of which the libraries have been removed from Debian for quite some time already, so clearly Debian is capable of not adding dependencies if they don't need to. So, no, we will not remove the GTK2 units. It's on Debian to just remove the dependency and to enforce Qt6 for Lazarus. They don't shy away from other downstream changes if they're necessary after all. ---------------------------------------------------------------------- dbannon · 2026-02-07 23:47 Quote from: PascalDragon on February 07, 2026, 10:12:10 pmQuote from: dbannon on February 06, 2026, 04:52:29 amThe easy solution of removing that package packages/gtk2 from FPC would make FPC acceptable to Debian (I think) but it will break Lazarus. FPC also contains a package for GTK1 of which the libraries have been removed from Debian for quite some time already, so clearly Debian is capable of not adding dependencies if they don't need to. So, no, we will not remove the GTK2 units. It's on Debian to just remove the dependency and to enforce Qt6 for Lazarus. They don't shy away from other downstream changes if they're necessary after all. This was all noted further back up this thread Pascal Dragon. Davo ---------------------------------------------------------------------- dbannon · 2026-02-07 23:57 Quote from: dsiders on February 07, 2026, 05:07:33 pmGTK3 was introduced 15 years ago. If it doesn't work now, it's not likely that it ever will. And even if it did, it's on the verge of becoming legacy too. GTK4 has been out for 5+ years. Well, given that GTK3 went from totally unusable to pretty close in a short time a few months ago, I suspect it might be just a case of someone (eg zelko) having some free time. I love Qt5/6 but recognize that a GTK* solution would be more popular with the general community. But, right now gtk3 is not ready, IMHO Qt6 is ! And we need to be seen solving this problem. Davo ---------------------------------------------------------------------- MarkMLl · 2026-02-09 09:01 This is not my fight any more, for reasons that have been discussed elsewhere,  and I prefer to keep my head down. Quote from: marcov on February 06, 2026, 02:53:39 pmKeep opening those tickets on the debian site and voting them up till they see the light I put it to you (Marco) that antagonising the Debian project will not be in the interest of the FPC and Lazarus communities, and will risk marginalising Pascal to an even greater extent than is current. However, I also note that a number of other projects are unhappy about the direction that Debian and other distreaux are moving, in particular their deprecation of X11 (in favour of Wayland) which obviously has a bearing on things like gtk. As a specific example I quote from the KiCad blog: QuoteWe try to be pragmatic. We support what works, we document what doesn’t, and we focus our development efforts where they’ll have most benefit for our users. We will adjust our position as Wayland improves, but we won’t compromise the reliability and functionality of KiCad. For now, if you need to use KiCad on Linux, use X11. There is substantially more detail at https://www.kicad.org/blog/2025/06/KiCad-and-Wayland-Support/ and I suggest that it is worth reading. Now, something like KiCad is obviously an important-enough application program that a user or group of users could shape their operating system choice entirely around its requirements. FPC/Lazarus developers could make a similar choice, although I suggest that the FPC/Lazarus projects would be on thin ice demanding that they make that choice. However, that would leave the thorny issue of the end-users on whose behalf those developers were working. The bottom line is that Pascal is one of the "Grand Old Languages" and deserves respect because of the concepts of strong types etc. that it introduced, even if its use is declining at some greater or lesser rate. I suggest that it is the responsibility of the FPC maintainers to not do anything that accelerates that decline. MarkMLl ---------------------------------------------------------------------- robert rozee · 2026-02-09 12:24 Quote from: MarkMLl on February 09, 2026, 10:01:25 amI put it [...] that antagonising the Debian project will not be in the interest of the FPC and Lazarus communities, and will risk marginalising Pascal to an even greater extent than is current.[...] MarkMLl i strongly agree. can i please repeat (part of) the list of questions i asked in Reply #9 of this thread: Quote2. assuming that all the 'offending' bits and pieces were moved from the FPC package to the Lazarus package, would the Debian developers then be happy with FPC? 3. similar questions, but wrt qt5 (or any other qt variant): are there qt bits contained within the FPC package? and could they similarly be moved to the Lazarus package? 4. once the FPC package has been rendered 'GTK and qt free' (and indeed free of any other widgetset dependencies), would it then be possible to create a Lazarus package that: contained NO binary executables or object files;from which FPC alone could [itself] rebuild all the binaries and object files necessary to run and use the Lazarus IDE and thence from which arbitrary Lazarus/FPC GUI applications could be built? it just seems to me that provided... A. the FPC package were made widgetset-free, and, B. the Lazarus package being distributed contained JUST source code, ... then the Debian folks would have nothing to complain about. the end user would then just need to: 1. install [the 'cleaned'] FPC (containing the already built FPC compiler), 2. install the Lazarus source code [only] package, 3. run a script [shipped with the Lazarus package] that [uses FPC to] build the Lazarus IDE [ELF binary], library object files, etc. both installs packages (1. and 2.) could [surely then] be [hosted in] from the Debian repositories, and both packages would be 'clean'; the "build script" from 3. would generate binaries and object files that depended solely upon existing libraries already installed on the local machine. i am looking at a solution SPECIFIC to x64 Linux versions for Debian of FPC 3.2.2 and Lazarus 3.8.0 (or thereabouts). the ONLY changes would be (1) removing some pre-built files, (2) changing some configuration files, adding a new 'rebuild me' script. NO version changes would be involved. this would NOT be a new branch. perhaps my take on the situation is a little simplistic? i would appreciate hearing feedback in particular from MarkMLl, Marcov, and Davo. cheer, rob   :-) ---------------------------------------------------------------------- MarkMLl · 2026-02-09 13:12 Part of the problem is that there are three separate groups of people involved. I think the consensus is that building FPC (as distinct from Lazarus) doesn't demand the presence of GTK v1/2/3 or Qt, even though it might build libraries capable of interfacing with them. As such, the FPC developers are blameless. The core Debian maintainers already have a big job on their hands trying to reconcile problems caused by Wayland, Systemd and so on. The Pascal community really /cannot/ afford to antagonise them. Whoever packages FPC into a Debian package has slipped up by assuming that because it includes GTK2 interface units it requires the presence ** of Debian's libgtk2.0-dev package: if it did then it would be impossible to recompile FPC on a non-GUI system. /That/ is where the problem lies, and /surely/ it can't be too difficult for the FPC maintainers to persuade them to see the error of their ways without upsetting the broader Debian community in the process. Considering Lazarus: the current/stable version of Debian ("Trixie", v13) has separate packages for different IDE widget sets: Quotelazarus-ide-gtk2/stable 4.0+dfsg-3 all   IDE for Free Pascal - Last GTK+ version dependency package lazarus-ide-gtk2-4.0/stable 4.0+dfsg-3+b1 amd64   IDE for Free Pascal - GTK+ version lazarus-ide-qt5/stable 4.0+dfsg-3 all   IDE for Free Pascal - Last Qt version dependency package lazarus-ide-qt5-4.0/stable 4.0+dfsg-3+b1 amd64   IDE for Free Pascal - Qt version As I've said (briefly) above, I can confirm that a binary FPC (3.2.2, loaded from the FPC repo, not from Debian) is able to recompile its own sources (ditto) on Trixie without problems provided that it's got the standard ncurses etc. prerequisite for its textmode IDE. I've not however checked a recent Lazarus. I've not checked, but I would have hoped that Debian's e.g. lazarus- ide-qt5 did not in itself have a dependency on gtk2. However that's of little use if (Debian's packaged) FPC has extraneous prerequisites, but that's the Debian package maintainers' problem rather than either the FPC developers/maintainers or the core Debian team. I have not attempted to look at later versions of Debian: my modus operandi is heavily oriented towards SSH with X11 etc., and if Debian refuses to support that combination I will either look elsewhere or will ensure that development systems are aggressively isolated. I'm not sure that answers all your questions (Robert), but I think it touches on most of them. Edited to add: ** There is a possibility that the package maintainer doesn't realise the extent to which the FPC compiler includes its own build system analogous to make, and that external libraries will not be referenced unless a program imports the interface units. MarkMLl ---------------------------------------------------------------------- marcov · 2026-02-09 13:17 Quote from: MarkMLl on February 09, 2026, 10:01:25 amQuote from: marcov on February 06, 2026, 02:53:39 pmKeep opening those tickets on the debian site and voting them up till they see the light I put it to you (Marco) that antagonising the Debian project will not be in the interest of the FPC and Lazarus communities, and will risk marginalising Pascal to an even greater extent than is current. Not doing anything and foregoing the hope of a Debian in-distro FPC package will do so also.  And probably numbers is the only thing that gets their attention since we already discussed till we were blue in the face with the maintainers in the bugreports mentioned in this thread. The package maintainers (Abou) are of course in a tough spot, and have navigated the disconnected between FPC's one distro vs debian's "factor everything out as a separate package" mentality for years. I suspect the package maintainers hit a wall when communicating with Debian brass too, but that is no excuse to dump it on our doorstep. Since what goes for GTK2 also goes for GTK1 (still default compiled too!), X11, SDL etc. Just because the Debian top brass pushes for wayland and thus gtk2 deprecation this suddenly becomes an issue. Since they now use global analysis tools to check for GTK2 status, this suddenly surfaces after being this way for 20+ years... Anyway to my best knowledge the "fpc" port is already a meta package consisting out of smaller debian package, it would make sense to simply remove the gtk2 package from  the FPC meta package, and add a dependency on it to the Lazarus package and other packages that might use it. (I don't know exactly how they handle Lazarus switching dependencies to various gtks and QTs). That's another way they could solve the problem themselves, anyway I'll see if I can add that suggestion to the bugreport later. QuoteHowever, I also note that a number of other projects are unhappy about the direction that Debian and other distreaux are moving, in particular their deprecation of X11 (in favour of Wayland) which obviously has a bearing on things like gtk. Probably, but that is more something for Lazarus to decide, as FPC is not really GUI orientated. ---------------------------------------------------------------------- MarkMLl · 2026-02-09 13:50 Quote from: marcov on February 09, 2026, 02:17:14 pmSince they now use global analysis tools to check for GTK2 status, this suddenly surfaces after being this way for 20+ years... So is the real problem that (in the absence of a Makefile) that tool assumes that the presence of gtk2 interface units requires the underlying library, without understanding that if the units aren't imported they have no effect? If necessary, could Debian's installation scripts build the questionable units? There's precedent there: libdvd being built on demand, Google Earth being installed externally and so on. MarkMLl ---------------------------------------------------------------------- robert rozee · 2026-02-09 15:00 what would happen if WE created an "FPC 3.2.2 x64 lite" package and submitted to the Debian folks for inclusion in their repositories? as i've said above, it would contain the exact same ELF binary of the FPC compiler, but have the GTK/qt/etc problematic bits removed. also, it would also lack any pre-built object files and other binaries (as far as possible), with these instead all being built at install-time on the user's own computer. how difficult would this be to accomplish? cheers, rob   :-) ---------------------------------------------------------------------- marcov · 2026-02-09 16:43 Quote from: MarkMLl on February 09, 2026, 02:50:52 pmQuote from: marcov on February 09, 2026, 02:17:14 pmSince they now use global analysis tools to check for GTK2 status, this suddenly surfaces after being this way for 20+ years... So is the real problem that (in the absence of a Makefile) that tool assumes that the presence of gtk2 interface units requires the underlying library, without understanding that if the units aren't imported they have no effect? I've no idea what was first, if the maintainers added some dependency to GTK2 based on some guideline and the scanner picked up on that, or that the tool simply picked up on the "GTK2" string somewhere and that was enough.  I also don't know who really deprecated the package (if it was somebody central running the scanners, or if they at least ran it over the official maintainers). You can see here that the current FPC "gtk2" units packag. (a package that they themselves split off from the main build cycle!) depends on libgtk2.0-dev. The FPC meta package   depends on that gtk2 package. QuoteIf necessary, could Debian's installation scripts build the questionable units? There's precedent there: libdvd being built on demand, Google Earth being installed externally and so on. They already do factor it out themselves. So I don't see why they couldn't fix this themselves. It is basically a modification in a division into packages they (or previous maintainers) created. The question is why the maintainers persist. Is making fundamental changes to the package hierarchy beyond their means? Or do they get swept up in the frantic quest to erase GTK2 ? Or do they expect that exceptions won't be accepted by high ups in the Debian chain? I don't know. All I know is that it is a problem of Debian's creation, and they somehow want to drop it on our doorstep as ours.  I assume sooner or later there will be a suggestion to use p2c to make the "difficult" part of FPC go away (being a self bootstrapping compiler). Wouldn't be the first time they suggested that, nor the second when they had to make an exception (a binary starting compiler). A later similar conflict issue was reproducible builds, that was then heavily pushed by the central debian organisation. ---------------------------------------------------------------------- PascalDragon · 2026-02-09 20:58 Quote from: robert rozee on February 09, 2026, 04:00:17 pmwhat would happen if WE created an "FPC 3.2.2 x64 lite" package and submitted to the Debian folks for inclusion in their repositories? as i've said above, it would contain the exact same ELF binary of the FPC compiler, but have the GTK/qt/etc problematic bits removed. also, it would also lack any pre-built object files and other binaries (as far as possible), with these instead all being built at install-time on the user's own computer. There is nothing we need to change for FPC, because Debian is perfectly capable of dealing with the situation that FPC also has units for GTK1 so they can just as well deal like that for GTK2. Just like marcov said they need to remove the reference from the fpc meta package to the fpc-gtk2 package and instead have lazarus depend on it (this obviously moves the issue to the lazarus package, but that is a different topic from the fpc package due to Lazarus indeed requiring some UI backend). ---------------------------------------------------------------------- MarkMLl · 2026-02-10 08:59 Quote from: PascalDragon on February 09, 2026, 09:58:13 pmThere is nothing we need to change for FPC, because Debian is perfectly capable of dealing with the situation that FPC also has units for GTK1 so they can just as well deal like that for GTK2. Just like marcov said they need to remove the reference from the fpc meta package to the fpc-gtk2 package and instead have lazarus depend on it (this obviously moves the issue to the lazarus package, but that is a different topic from the fpc package due to Lazarus indeed requiring some UI backend). FWIW I agree (although I'd have written "Debian /should/ /be/ perfectly capable"), but my point is that they shouldn't be antagonized. Edited to add: FPC has interface units for e.g. libusb, but superficial examination doesn't show a prerequisite of libusb-1.0-0-dev or libusb-dev expressed in the Debian package dependencies. MarkMLl ---------------------------------------------------------------------- robert rozee · 2026-02-10 09:20 Quote from: PascalDragon on February 09, 2026, 09:58:13 pmThere is nothing we need to change for FPC, because Debian is perfectly capable of dealing with the situation [...] while Debian is "perfectly capable of...", there remains the sticky point that Debian may choose to NOT "deal with the situation". if Debian does nothing, FPC will (from what others have suggested) be removed from the Debian repositories. what makes everyone so certain that Debian will suddenly 'see the light'? they have little to lose, whereas for the wider Pascal community (not just FPC) the loss seems somewhat more substantial. but for a ha'porth of tar+ we could act to ensure FPC 3.2.2 was brought back into the Debian repositories, and once there with a little lobbying amongst the Debian-derivative distros have it even more widely available. does anyone even care? it strikes me that the current FPC developers are more interested in tinkering with their (perpetual) beta code, while abandoning the working compiler (3.2.2) that the rest of the world has been using for the last 4.5 years. cheers, rob   :-( + "but for a ha'porth of tar the ship was lost" (and other similar variations) ---------------------------------------------------------------------- dbannon · 2026-02-10 10:45 Quote from: robert rozee on February 10, 2026, 10:20:44 am while Debian is "perfectly capable of...", there remains the sticky point that Debian may choose to NOT "deal with the situation". if Debian does nothing, FPC will (from what others have suggested) be removed from the Debian repositories. Robert, Debian has a "Pascal Team" of several people of varying degrees of activeness. They are both committed and capable but, obviously, need to work within Debian guidelines.  In the past, Abou has been very active with the packaging of FPC/Lazarus but I have not seen anything from him for a few weeks. Another person, Mazen, seems to be concentrating on gir2pas to try and deal with the problem, I have asked for clarification but not got anywhere yet. https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-pascal- devel I have a current debian unstable box that has gtk2, FPC, Lazarus and my app still available so not really sure whats happening. Lots of notices flying around saying they have been removed. I do believe however, it will be OK. The important issue was that the dependency on gtk2 was, apparently, added to the Debian source package by mistake, perhaps a long time ago when every box did have gtk2 and it did not matter. Many people, me especially, assumed it was there for a good reason (despite being told otherwise by Marcov and PascalDragon). Be nice to hear from someone from that team to be honest. Lazarus is, of course, the next issue ! (My advice to anyone using Lazarus on Linux is to download and build the source, see  https://github.com/davidbannon/FPC_Laz_Install/blob/m ain/compile_fpc.bash) Davo ---------------------------------------------------------------------- Fred vS · 2026-02-10 11:19 Hey guys, why are you tilting at windmills? Regarding "remove GTK2 (and so fpc-lazarus) from Debian," are you sure that applies to the entire Debian project? As far as I know, Ubuntu uses Debian and has several variants without Wayland (which is the number one problem): Xubuntu and Lubuntu, which certainly won't remove GTK2. And as for the "Wayland-only" distros, well, forget about them. ---------------------------------------------------------------------- marcov · 2026-02-10 18:46 Quote from: dbannon on February 10, 2026, 11:45:16 am Robert, Debian has a "Pascal Team" of several people of varying degrees of activeness. They are both committed and capable but, obviously, need to work within Debian guidelines.  In the past, Abou has been very active with the packaging of FPC/Lazarus but I have not seen anything from him for a few weeks. Another person, Mazen, seems to be concentrating on gir2pas to try and deal with the problem, I have asked for clarification but not got anywhere yet. https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-pascal- devel Thanks, I read them, and some observations I considered noteworthy: Abou  (the current .deb maintainer) seems to understand (24 jan) that for FPC removing the gtk2 dependency from fp-gtk2units is the only short time viable optionI only see robot messages about GTK2 package deprecations on that maillist. Seems no verdict from humans/Debian brass yet, so they might get away with that and reinstate FPC relatively quicklyFrom his posts I also gather that GTK2 is deprecated absolutely (as it will not be there in testing, so moving the dependency to Lazarus won't do much good), so Lazarus will have to use something else, mostly likely some QT. Possibly even as flatpack with matched qtpas.Mazen (a former .deb maintainer) wants to generate headers from girs. However since I did the same for Windows to use Aravis, I know using them will break occasionally as the GIR or the translator changes how an instruction is encoded or translated. I hope they choose to long term maintain generated headers rather than regularly (or dynamically) blindly regenerating with the .gir or gir2pas du jour. As for Fred's remark about the "entire" debian process, nearly everything debian derived uses Debian upstream. Normally such move would be death sentence to GTK2,  but since the attached Wayland subject is very political, it is hard to predict what will happen. There is also time, since trixie became stable last august, I guess we have till summer 2027, and maybe a small year before a course becomes definitive. Even if some releases/spins will opt out, that will be hard on themselves, since they will have to do (much) more work to track upstream. It essentially becomes a fork tracking at a distance instead of a packaging spin. They might hold out a major debian cycle as a protest, but most won't last longer than one before conforming. And even if they keep X, they might not keep GTK2. ---------------------------------------------------------------------- AmatCoder · 2026-02-10 18:47 Quote from: Fred vS on February 10, 2026, 12:19:14 pmRegarding "remove GTK2 (and so fpc-lazarus) from Debian," are you sure that applies to the entire Debian project? As far as I know, Ubuntu uses Debian and has several variants without Wayland (which is the number one problem): Xubuntu and Lubuntu, which certainly won't remove GTK2. Why not? GTK2 is one thing, and another thing is Wayland. Neither Xubuntu (Xfce -> GTK3) nor Lubuntu (LXQt -> Qt6) are using GTK2 anymore... They are still using X11 (for the time being) but not GTK2... GTK2 will be removed from Debian in the near future. And, of course, its derivatives as well (Ubuntu, Linux Mint etc). Arch Linux already did it. ---------------------------------------------------------------------- Fred vS · 2026-02-10 19:12 Quote from: AmatCoder on February 10, 2026, 07:47:58 pmGTK2 will be removed from Debian in the near future. OK (it is sad because GTK2 works very well). So, for Lazarus, the default widgetset should be Qt. What bothers me a bit about Qt is that the qt4pas library has to be installed and it's not possible to load it dynamically (maybe I'm missing something there). And for Wayland,  I  . ---------------------------------------------------------------------- dbannon · 2026-02-11 00:08 Yeah, sure, a large percentage of linux distros are Debian based. Some, like ubuntu take a regular (twice yearly) snapshot of Testing, others wait for a Debian to decide that Testing is ready (~2 years) to migrate to release and derive their distro from the released version. Obviously, there is no reason that a Debian derived distro could not reintroduce the gtk2 libraries back into their own repos but I cannot imagine why they would bother. Similarly, a user could download and build gtk2 onto their own system. But why ? As far as Linux Desktops that use Gnome 2, Mate and Cinnamon for example, I doubt they actually make direct calls to the gtk2 libraries that we are familiar with.  They are continuing the Gnome 2 interface, not necessarily the use of gtk2. Mate uses mostly gtk3 I believe. Use of Wayland is inherent to a Desktop, not a Distro. My Mate Desktop does no use Wayland (yet). Gnome and KDE (infamous for using Wayland) could be rebuilt to not use Wayland. I dislike both interfaces so its not going to be me ! Davo ---------------------------------------------------------------------- tk · 2026-02-11 12:36 Quote from: dbannon on February 06, 2026, 04:52:29 amFolks, as some of you already know, Debian has removed FPC/Lazarus from its Forky (ie unstable) repo. This is because they are dropping support for gtk2 and both FPC and Lazarus (appear) to depend on the much out of date gtk2 ! This affects us as well. Does this mean that even gtk2 libraries themselves will be removed at some time and Lazarus programs suddenly stop working after some Linux update in the future? Will it just be removed from the default install or entirely (not available even through "sudo apt-get install gtk2.0")? ---------------------------------------------------------------------- MarkMLl · 2026-02-11 13:43 Quote from: tk on February 11, 2026, 01:36:59 pmWill it just be removed from the default install or entirely (not available even through "sudo apt-get install gtk2.0")? At present Debian's package search shows it being present in versions (strictly) less than experimental, but the writing is firmly on the wall. Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i $ rmadison -u qa libgtk2.0-dev libgtk2.0-dev | 2.24.33-2+deb11u1 | bullseye | amd64, arm64, armhf, i386 libgtk2.0-dev | 2.24.33-2+deb12u1 | bookworm | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x libgtk2.0-dev | 2.24.33-7         | trixie   | amd64, arm64, armel, armhf, i386, ppc64el, riscv64, s390x libgtk2.0-dev | 2.24.33-10        | forky    | amd64, arm64, armhf, i386, ppc64el, riscv64, s390x libgtk2.0-dev | 2.24.33-10        | sid      | amd64, arm64, armhf, i386, loong64, ppc64el, riscv64, s390x  I'd point you to what happened to GTK v1, where the development package was removed from the distro after Lenny: Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i $ rmadison -u archive libgtk1.2-dev libgtk1.2-dev | 1.2.7-1     | debian/potato  | alpha, arm, i386, m68k, powerpc, sparc libgtk1.2-dev | 1.2.10-11   | debian/woody     | alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc libgtk1.2-dev | 1.2.10-17   | debian/sarge     | alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc libgtk1.2-dev | 1.2.10-18   | debian/etch      | alpha, amd64, arm, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc libgtk1.2-dev | 1.2.10-18   | debian/etch-m68k | m68k libgtk1.2-dev | 1.2.10-18.1 | debian/lenny     | alpha, amd64, arm, armel, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc  Note that the rmadison tool supports  -u archive  and  -u qa  but in neither case shows the experimental branch. MarkMLl ---------------------------------------------------------------------- sfeinst · 2026-02-11 15:14 Quote from: tk on February 11, 2026, 01:36:59 pmThis affects us as well. Does this mean that even gtk2 libraries themselves will be removed at some time and Lazarus programs suddenly stop working after some Linux update in the future? Will it just be removed from the default install or entirely (not available even through "sudo apt-get install gtk2.0")? I may be reading apt list wrong, but I think they have already started to remove some gtk2 related items.  I am running trixie.  As an example, I compiled my apps using Lazarus and gtk2.  When I run the app from the command line, I see the following error in the command prompt: Failed to load module "canberra-gtk-module" I have read this can be ignored.  I have searched the repos and I see a canberra for gtk3, but not gtk2, which leads me to believe debian has started to phase out the gtk2 libraries.  Though it could just be a Wayland thing.  But I interpret it as a start of gtk2 incompatibilities. ---------------------------------------------------------------------- tk · 2026-02-11 21:21 Quote from: sfeinst on February 11, 2026, 04:14:28 pmI have read this can be ignored.  I have searched the repos and I see a canberra for gtk3, but not gtk2, which leads me to believe debian has started to phase out the gtk2 libraries.  Though it could just be a Wayland thing.  But I interpret it as a start of gtk2 incompatibilities. Hmm, this is bad. However, I tested now with GTK3 and although it is still not usable for me, it shows some progress (confirmed here https://forum.lazarus.freepascal.org/index.php/topic,70538.0.html). Hopefully we have usable GTK3 port before GTK2 support officially ends. ---------------------------------------------------------------------- dbannon · 2026-02-12 00:41 Quote from: sfeinst on February 11, 2026, 04:14:28 pm... trixie Failed to load module "canberra-gtk-module" No, thats not an indication they are removing things from Trixie, thats not something that would ever, intentionally happen. Thats an issue, been around for a long time. You can add canberra to your link list and it will go away, however, probably just ignore it ! Some gtk2 library thinks, incorrectly, it needs canberra. Hell, I am Australian and I doubt we need Canberra ! So far, my Debian Unstable box does have gtk2, fpc, Lazarus  and even my app, tomboy-ng still there. In the debian model, packages are removed and returned to unstable and even Testing quite often so, happening, if it happens, is not necessarily fatal. But its pretty sure, IMHO, that gtk2 will NOT be in Forky when its released in 2027 ! (remember, eg Ubuntu takes Testing twice a year so it will probably release without gtk2 before then.) Honestly, thats not that bad, we need to adapt. We have established nothing needs to be done by the fpc dev to FPC. Apart from being 4.5 years old, its OK. Different matter with Lazarus where changes are possible. We could do nothing and expect Debian to change their package to use Qt5/6 and continue to release, in the Lazarus Official package, a widget set that will not install in new systems. Be pretty silly IMHO. Not a time for "Masterful Inaction" ! Davo ---------------------------------------------------------------------- dbannon · 2026-02-12 00:54 OK, clearer picture. Please look at https://tracker.debian.org/pkg/tomboy-ng It has my app marked as - Version 0.42-1 of tomboy-ng is marked for autoremoval from testing on Fri 13 Mar 2026. It depends (transitively) on fpc, lazarus, affected by #967348, #967564. You should try to prevent the removal by fixing these RC bugs. So, saying its marked for removal has a time line !  FPC, Lazarus all have similar marks. Davo ---------------------------------------------------------------------- tk · 2026-02-12 08:34 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967348 QuoteGTK 2 is used by some important productivity applications like GIMP, and has also historically been a popular UI toolkit for proprietary software that we can't change, so perhaps removing GTK 2 from Debian will never be feasible. However, it has reached the point where a dependency on it is a bug - not a release-critical bug, and not a bug that can necessarily be fixed quickly, but a piece of technical debt that maintainers should be aware of. So they PERHAPS never remove GTK2. Good joke In that case, the justification for removing fpc, lazarus, and other similar applications sounds pretty weak... https://lists.debian.org/debian-devel/2026/01/msg00090.html QuoteAs mentioned in our 2020 MBF [4], besides being unmaintained for years, GTK 2 does not support either HiDPI or native Wayland. Also very weak reason, just imagine MS removes much older GDI... ---------------------------------------------------------------------- kupferstecher · 2026-02-12 10:46 Quote from: dbannon on February 12, 2026, 01:41:06 amSo far, my Debian Unstable box does have gtk2, fpc, Lazarus  and even my app, tomboy-ng still there. When a Lazarus application is shipped with a distro, is this always done as binary, or do you need to provide building scripts including scripts to build the compiler and IDE for building your Lazarus programm? ---------------------------------------------------------------------- dbannon · 2026-02-13 01:09 Quote from: kupferstecher on February 12, 2026, 11:46:26 amQuote from: dbannon on February 12, 2026, 01:41:06 amSo far, my Debian Unstable box does have gtk2, fpc, Lazarus  and even my app, tomboy-ng still there. When a Lazarus application is shipped with a distro, is this always done as binary, or do you need to provide building scripts including scripts to build the compiler and IDE for building your Lazarus programm? The Debian model is the same for all (non-script) applications. The maintainer (in tomboy-ng's case, me) makes (and tests) a source package. No binary, just the source and some config files describing build and run dependencies. My app depends on (eg) FPC and Lazarus so they need to already be in the repo. That source package is sent to a "mentor", a Debian person who looks, critically, at the packaging and, if happy will put the source package into the experimental repo. Auto running processes then builds that source package for each of the required platforms. Both source packages and binary packages are available from the Debian repos. In the case of FPC and Lazarus, their maintainers are Debian insiders but separation of roles still takes place. Davo ---------------------------------------------------------------------- AmatCoder · 2026-02-13 17:18 It is also important to take into account: GTK 3 is in maintenance-only mode since 2019. It may reach EOL around 2028 (estimated) Qt5 had already reached EOL on May 2025 So all of you should port your projects to Qt6. ---------------------------------------------------------------------- kupferstecher · 2026-02-13 21:29 Quote from: dbannon on February 13, 2026, 02:09:35 amNo binary, just the source and some config files describing build and run dependencies.I see. So a working official FPC/Lazarus is really critical. ---------------------------------------------------------------------- dbannon · 2026-02-17 10:38 OK, it seems FPC is reasonably safe in Debian now. https://tracker.debian.org/pkg/fpc Been a few in, then out, then in agains but I think we can assume its good now. So, how about Lazarus ?  I am unsure if the Debian packagers will be willing to package a widgetset other than the one chosen as default by the Lazarus developers. I quote "Version 4.4+dfsg-4 of lazarus is marked for autoremoval from testing on Fri 13 Mar 2026. It is affected by #967564. The removal of lazarus will also cause the removal of (transitive) reverse dependencies: astap, astap-cli, cevomapgen, cqrlog, ddrescueview, dozzaqueux, goverlay, lazpaint, libqt6pas, morserunner, mricron, optgeo, tomboy- ng, transgui, udm, vmg, winff. You should try to prevent the removal by fixing these RC bugs." Davo ---------------------------------------------------------------------- robert rozee · 2026-02-17 12:29 Quote from: dbannon on February 17, 2026, 11:38:28 amOK, it seems FPC is reasonably safe in Debian now. [...] So, how about Lazarus ? [...] I quote: "Version 4.4+dfsg-4 of lazarus is marked for autoremoval from testing on Fri 13 Mar 2026-...]" Davo as i raised in one of the other threads: Quote from: robert rozee on February 15, 2026, 01:22:41 pm[...] btw - is it technically possible for a GUI application to be built such that it can detect the available widget sets and just use whatever one is available? ie, dynamically load the necessary libraries at run-time using dlopen/etc. and Fred vS confirmed as possible: Quote from: Fred vS on February 15, 2026, 01:35:10 pm[...] Yes, of course, it's possible (I've done it for X11 libraries), but it requires a bit of effort to convert the Pascal headers using "external" methods with the variable returned by `DynLibs.GetProcedureAddress()`. Then, at init of the app, check which  widget sets is installed using `DynLibs.LoadLibrary()`. i have previously played around with adding a unit into a project1.lpr to run code prior to GTK's startup: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program project1; {$mode objfpc}{$H+} uses  {$IFDEF UNIX}{$IFDEF UseCThreads}  cthreads,                                    // UNIX + CThreads  {$ENDIF}  start,                                       // UNIX only, startup code before GTK is initialized (test)  {$ENDIF}   Interfaces,                                // this includes the LCL widgetset  Forms, Unit1; {$R *.res} begin  RequireDerivedFormResource:=True;  Application.Initialize;  Application.CreateForm(TForm1, Form1);  Application.Runend. for my testing the start unit just printed out a greeting message to the console, which was sufficient to confirm that the greeting message was displayed before GTK started complaining about spurious initialization errors - as it is inclined to do on occasion! (as Fred vS says) a start unit could detect the available widget set(s), and for whichever one is used (qt6 as 1st choice, fallback to qt5 as 2nd choice, fallback to GTK2 as final choice) build a table of entry points that can be made globally available. then someone would just need to go through all the source code for the Lazarus IDE and edit every external statement to instead create function pointer variables (or whatever the term is!) using the entry point table created by the start unit. for accessing the ALSA sound system in one of my projects, a year or so back i converted code that previously used EXTERNAL statements as follows: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i // OLD VERSION, using external:// function snd_pcm_open(pcm: PPsnd_pcm_t; name: PChar;//      stream: snd_pcm_stream_t; mode: cint): cint; cdecl; external libasound;// [...] // have now switched to "Dynamic Loading" on use, the following variables will hold the dynamically loaded ALSA methodsvar snd_pcm_open:function(pcm: PPsnd_pcm_t; Name: PChar; stream: snd_pcm_stream_t; mode: cint): cint; cdecl;[...]    ALSAhandle:TLibHandle={dynlibs.}NilHandle;         // this will hold our handle for the ALSA library  procedure ALSAstartup;var ALSAname:string='libasound.so.2';begin  ALSAhandle:={DynLibs.}SafeLoadLibrary(ALSAname);     // obtain the handle we want  if ALSAhandle<>{DynLibs.}NilHandle then              // handle was obtained OK  begin                                              // tie functions to the VARs from above    Pointer(snd_pcm_open):={DynLibs.}GetProcedureAddress(ALSAhandle, PChar('snd_pcm_open'));[...]  endend;  procedure ALSAshutdown;begin  if ALSAhandle<>{DynLibs.}NilHandle then  begin    {DynLibs.}UnloadLibrary(ALSAhandle);    ALSAhandle:={DynLibs.}NilHandle  endend; (credit to Fred vS for showing me how to do the above) in principal it seems that the above approach could be applied to the whole of the Lazarus IDE - it would be a large task, but on the whole mostly an 'automated' conversion for the programmer doing the work. once the concept is proven, it could then be streamlined for others to use going forward with their own Lazarus/FPC projects for widget set auto-selection. (see addendum below, just adding in the start unit to project1.lpr would suffice) cheers, rob   :-) addendum 1: in the above i forgot to include one more step - merging what are (presumably) conditional compile blocks for each widget set, into case statements (or similar) to select which set of code for which widget set. to some (yet to be determined) extent this would grow the size of generated ELF files, but these days folks don't seem to worry so much about this! addendum 2: it is actually even easier. the start unit just needs to set a single global variable that indicates the widget set that should be used. then every external statement replaced with calls to SafeLoadLibrary and GetProcedureAddress, it looks like it may ok to call  SafeLoadLibrary multiple times to get the same handle returned each time. conditional compile blocks (selecting for different widget sets) then replaced with "if widget_set = GTK2/Qt5/Qt6 then ..." blocks. ---------------------------------------------------------------------- PascalDragon · 2026-02-17 19:52 Quote from: robert rozee on February 17, 2026, 01:29:02 pmas i raised in one of the other threads: Quote from: robert rozee on February 15, 2026, 01:22:41 pm[...] btw - is it technically possible for a GUI application to be built such that it can detect the available widget sets and just use whatever one is available? ie, dynamically load the necessary libraries at run-time using dlopen/etc. and Fred vS confirmed as possible: Quote from: Fred vS on February 15, 2026, 01:35:10 pm[...] Yes, of course, it's possible (I've done it for X11 libraries), but it requires a bit of effort to convert the Pascal headers using "external" methods with the variable returned by `DynLibs.GetProcedureAddress()`. Then, at init of the app, check which  widget sets is installed using `DynLibs.LoadLibrary()`. While technically possible does not mean that it's feasible. For the LCL it simply is not worth the effort this would require. ---------------------------------------------------------------------- robert rozee · 2026-02-17 21:22 Quote from: PascalDragon on February 17, 2026, 08:52:36 pmWhile technically possible does not mean that it's feasible. For the LCL it simply is not worth the effort this would require. PascalDragon: are you also one of the Lazarus developers? i thought you were on 'team FPC'. the advantages seem enormous, not only does it solve the Debian issue, it also yields ELF binaries that are far more universal, in the sense that they will run against multiple widget sets. and it is a chance to begin cleaning out all but the GLIBC dependencies from the ELF Symbol Table. on the other hand, since the vast majority of Lazarus/FPC users are on the Windows platform (67.7% as of January 2026), it could be argued that no effort for Linux Desktop (4.02%) support is justified. what do the Lazarus developers think? cheers, rob   :-) ---------------------------------------------------------------------- Martin_fr · 2026-02-17 21:45 Quote from: robert rozee on February 17, 2026, 10:22:34 pmQuote from: PascalDragon on February 17, 2026, 08:52:36 pmWhile technically possible does not mean that it's feasible. For the LCL it simply is not worth the effort this would require. PascalDragon: are you also one of the Lazarus developers? i thought you were on 'team FPC'. the advantages seem enormous, not only does it solve the Debian issue, it also yields ELF binaries that are far more universal, in the sense that they will run against multiple widget sets. and it is a chance to begin cleaning out all but the GLIBC dependencies from the ELF Symbol Table. on the other hand, since the vast majority of Lazarus/FPC users are on the Windows platform (67.7% as of January 2026), it could be argued that no effort for Linux Desktop (4.02%) support is justified. what do the Lazarus developers think? I have to back up PascalDragon. Even if someone started this fulltime now, it wouldn't be do-able in time. Even if we ignore the existing design issues in some of that code. Start with the obvious -> a dual exe must contain WS code for e.g. Gtk2 and QT5 (or 6). At least gtk is afaik hard linked to some gtk libs? So all those calls need to be replaced with LoadLibrary, getting the function pointer and using that. That is in theory a simple task, a search and replace... But in real live, if you change that many such calls, there will be somewhere some slight misses. And then you will have lengthy debug sessions. That is, if you spot it. It may affect something that only gets spotted in a few month => that is why there are lengthy RC times, and a fixes branch long before it makes a major release. Then the WS are tightly bound to the LCL. That is done by the linker. That again needs (best scenario, if it actually is possible) be replaced by runtime connecting. The WS is exposed in a couple of different ways, they all need to be found. I don't even have a complete list. Then if you completed that list, and executed it, it all needs to be tested. And you need to give 3rd parties time to test some such fundamental change. So, if that was started today, by someone who will spent fulltime (~40 hours a week) on this, and they are really really good, and they deliver a first draft in a few month (awfully optimistic), then that still needs to sit in the main branch for at least another 6 month of testing (if not more). And after that would be branched into a fixes branch, that would have to mature yet another 6 month before release. Unfortunately, other than that generic insight, I am not very familiar with the various WS for Linux. So I can't say much on what ways there are to go. I have seen talk on it, but I can't judge it much myself. So unfortunately I can't currently contribute to a solution here. ---------------------------------------------------------------------- marcov · 2026-02-17 21:53 Quote from: robert rozee on February 17, 2026, 10:22:34 pmon the other hand, since the vast majority of Lazarus/FPC users are on the Windows platform (67.7% as of January 2026), it could be argued that no effort for Linux Desktop (4.02%) support is justified. The numbers are even way more skewed if you actually regard binary distribution over distribution borders. That is even a fraction of that number. ---------------------------------------------------------------------- robert rozee · 2026-02-17 22:13 Quote from: Martin_fr on February 17, 2026, 10:45:31 pmEven if someone started this fulltime now, it wouldn't be do-able in time. so instead we do what? just sit back and wait for there to be even less "time"? assuming the desire is to still ship a Lazarus IDE ELF/Linux binary for AMD64, the alternative is to embrace there being multiple 'sub- versions' of the IDE's binary: Lazarus IDE built for GTK2Lazarus IDE built for Qt5Lazarus IDE built for Qt6 multiply the above list by AMD64, i386, RPi and we now have NINE variants of the ELF file to contend with! and i am sure the list will only get longer. oh, and there is also X11 vs Wayland to contend with. that could take the count up to EIGHTEEN. or do we abandon GTK2? but as others have pointed out, we are living in 'times of transition', where the is no one widget set that can be assumed as available on all desktop installations. drop GTK2 (as a pre-built Lazarus IDE) in favour of Qt5 and suddenly a whole lot of Linux desktops will be excluded. cheers, rob   :-) ---------------------------------------------------------------------- dbannon · 2026-02-17 23:16 Robert, I cannot see what you are trying to achieve here. While it might be possible, much like cycling across the Simpsom Desert, it would be hard, problem prone work that achieves little. If you are still trying to soften the blow of losing gtk2, no it would not help. To make and test and debug you will still need gtk2 installed. To use the gtk2 mode, your end users will still need gtk2 installed. And gtk2 is going away. Testing and debugging would be particularly difficult. My project, tomboy-ng, has about 40 or 50 {$ifdef LCLwidget} Linux directives. And, despite FPC/Lazarus's truly brilliant "write one, compile anywhere" they are mostly necessary. Which would you assert in your model at compile time ? On the other hand, in my github repo, I make available packages for gtk2, Qt5, Qt6 (and Win32, Cocoa) on various various hardware platforms. Easily built and handled at release time and easily understood by reasonably informed end users. Sorry, I cannot see the problem you are trying to solve ? The real issue is that Lazarus Developers need to make a decision about the next default widget set on Linux. The world is waiting on that decision. Davo OK, maybe not the whole world but some of us. ---------------------------------------------------------------------- robert rozee · 2026-02-18 01:51 Quote from: dbannon on February 18, 2026, 12:16:00 amRobert, I cannot see what you are trying to achieve here. [...] The real issue is that Lazarus Developers need to make a decision about the next default widget set on Linux. The world is waiting on that decision. Davo OK, maybe not the whole world but some of us.  i lament over the fracturing of Linux distributions. at least with MS Windows a single .exe can still run on every version of Windows that supports the win32 framework - that being from Windows 2000 up to Windows 11. in some cases even as far back as Windows 98SE. i know this because i still use Delphi 5 Professional, released in the year 2000 and running on an XP VM, to successfully generate some packages that run on Windows 11. the Linux Desktop, on the other hand, has simply fragmented. we have GTK2 vs Qt5 vs Qt6, all mutually incompatible. then we have X11 vs Wayland, with distros wanting to deprecate X11, while Wayland still (according to others) is barely usable. and the list goes on. i see TWO paths forward in the case of FPC/Lazarus on Linux - either: bind in support for everything (as much as is possible) in the one ELF binary, OR,distribute the Lazarus IDE package as source-only for the end user to build on their local machine, thereby guaranteeing the IDE and generated applications should be runnable locallya third option (3.) of switching the distributed ELF binary of the Lazarus IDE to Qt5 or Qt6 only, i see as a disaster. there are now, and will remain for a good few years, too many existing GTK2-only desktops; we are simply stuck having to support GTK2 in one way or another for the foreseeable future. so i advocate for either of 1. or 2. you prefer 2. that is fine, i'm ok with 2. i'd prefer 1., but 2. is workable. but something needs to be done. because when a user tries to click on the icon for an ELF binary that has unmet dependencies, NOTHING HAPPENS. no feedback, no error message. this is a major failing in the implementation of ALL Linux desktops. this 'just nothing', as if they had expectantly clicked on a blemish on their LCD screen, will result in users (aka "customers") walking away - something we desperately need to avoid at all cost. cheers, rob   :-) ---------------------------------------------------------------------- dbannon · 2026-02-18 03:10 Quote from: robert rozee on February 18, 2026, 02:51:03 amthe Linux Desktop, on the other hand, has simply fragmented. Agreed, its opensource at it best and worst ! Quotewe have GTK2 vs Qt5 vs Qt6, all mutually incompatible. ... and gtk3, gtk4 and, probably Qt7. But not mutually incompatible, they can all sit happily beside each other. QuoteX11 vs Wayland,you missed LibreX, Fred will have a piece of you for that. Quotebind in support for everything (as much as is possible) in the one ELF binary, OR,distribute the Lazarus IDE package as source-only for the end user to build on their local machine, thereby guaranteeing the IDE and generated applications should be runnable locally a third option (3.) of switching the distributed ELF binary of the Lazarus IDE to Qt5 or Qt6 only, i see as a disaster.... existing GTK2-only desktops No, I doubt there more than a few gtk2 only Linux desktops around, even now. Just about ever one will have gtk3 installed, almost all will support Qt5. And, as time goes by, more so. If someone chooses to use a ten year old operating system, they should expect to be limited in their software choices. But sure, the transition would have to be managed .... Quoteyou prefer 2. That is fine, i'm ok with 2. i'd prefer 1., but 2. is workable. but something needs to be done. because when a user tries to click on the icon for an ELF binary that has unmet dependencies, NOTHING HAPPENS. No, I prefer [2] for my use, I feel its not for everyone. But if some work was put into it, made, for example, as seemless as a rebuild of Lazarus when its files are in read-only space, it could work. gtk3 is not, now, ready. But I wonder if some special effort in that direction could be a better answer.  No, not "no error msg" if widget set is unavailable, just no GUI msg. And easily fixed. As you have discovered, a linux LCL app can do a whole lot of stuff before it starts the GUI engine. In my app, I read the command line, possibly do some note imports or exports and then check to see if there is already an existing instance running (and take appropriate action). Could be lots of arguments on best way to determine if the right widget set is available and right way to notify user, but do-able IMHO. Just a pascal unit that a programmer could choose to include. Maybe a fun project. Davo ---------------------------------------------------------------------- robert rozee · 2026-02-18 03:25 Quote from: dbannon on February 18, 2026, 04:10:48 am[...] No, not "no error msg" if widget set is unavailable, just no GUI msg. And easily fixed. As you have discovered, a linux LCL app can do a whole lot of stuff before it starts the GUI engine. In my app, I read the command line, possibly do some note imports or exports and then check to see if there is already an existing instance running (and take appropriate action). Could be lots of arguments on best way to determine if the right widget set is available and right way to notify user, but do-able IMHO. Just a pascal unit that a programmer could choose to include. Maybe a fun project. Davo [i'm getting off-topic here] unfortunately many users are not able to (capable of) launching a terminal window and running a GUI application from it. yes - that way does yield an error message, but trust me - i have tried - for many folks it is well nigh impossible to talk them through starting up a terminal, navigating to the right place where their application resides, then even typing in the "./" followed by the application's name! what Linux desktops lack is a 'universal' way of popping up a message window on the desktop. zenity does a passable job, but isn't universally available, and i've not found anything else that is. closest is perhaps launching a python script, but then does python have any universally available GUI abilities? or one can launch a terminal window and use that? i've done that before, but it does look extremely 'clunky' and different distros have different names to run a terminal window. or perhaps talk directly to X11 to just create the one error message window? i am open to suggestions! btw, is it possible, when using lazbuild to build a project, to specify the widget set to be built against? or is it more complicated than this. i must confess, i have never tried. i've always just stuck with the default of GTK2. cheers, rob   :-) ---------------------------------------------------------------------- Thausand · 2026-02-18 04:12 Quote from: robert rozee on February 18, 2026, 04:25:19 ambtw, is it possible, when using lazbuild to build a project, to specify the widget set to be built against? or is it more complicated than this. i must confess, i have never tried. i've always just stuck with the default of GTK2. wiki https://wiki.freepascal.org/lazbuild Quote--widgetset= or --ws=     override the project widgetset. e.g. gtk, gtk2, qt, win32, or carbon. PS: have you aware MSE (Martin. S. (rip)) and fpGUI (Graeme G.) that not have depend (LCL) widgetset ? ---------------------------------------------------------------------- dbannon · 2026-02-18 04:47 Quote from: robert rozee on February 18, 2026, 04:25:19 am.... what Linux desktops lack is a 'universal' way of popping up a message window on the desktop. zenity does a passable job, zenity is easy, its small and all you need do is make it a dependency of your app to ensure its available. It does of course depend on GTK3 but that is going to be on almost all distros for another ten years IMHO. Libnotify is a touch more elegant and, I think, universally available ?  There are lots of other alternatives. Quotebtw, is it possible, when using lazbuild to build a project, to specify the widget set to be built against? or is it more complicated than this. i must confess, i have never tried. i've always just stuck with the default of GTK2. The normal approach is to define, in Lazarus a build mode for each widgtset you support. But you can also do it on the FPC command line defining the appropriate constant. Bit harder to get your link line right but not that hard. Mode ?  Project->Options->Additions&Overrides.  Add a new build mode for every widget, then, in the grid line them up. Easy to see, hard to describe in words. Davo ---------------------------------------------------------------------- MarkMLl · 2026-02-18 08:13 Quote from: robert rozee on February 17, 2026, 10:22:34 pmWhile technically possible does not mean that it's feasible. For the LCL it simply is not worth the effort this would require.[/quote] Not relevant. What /is/ relevant is that it would mandate a single set of interface objects with no opportunity for the IDE or programmer to work around them, and irrespective of how much work was put into it most people would find that their programs break. MarkMLl ---------------------------------------------------------------------- Thaddy · 2026-02-19 11:26 Quote from: marcov on February 17, 2026, 10:53:49 pmQuote from: robert rozee on February 17, 2026, 10:22:34 pmon the other hand, since the vast majority of Lazarus/FPC users are on the Windows platform (67.7% as of January 2026), it could be argued that no effort for Linux Desktop (4.02%) support is justified. The numbers are even way more skewed if you actually regard binary distribution over distribution borders. That is even a fraction of that number. Two things: 1. Linux users prefer to install from their distro's repository. We have no insight in those installs 2. Many Linux users prefer to build from source, either the documented proper way or the convenient fpcupdeluxe way. Windows users are less likely to use any of thosder two because their eco-system needs adjustments for 1. and 2. feels alien to them. ---------------------------------------------------------------------- robert rozee · 2026-02-19 12:20 Quote from: MarkMLl on February 18, 2026, 09:13:31 am[...] What /is/ relevant is that it would mandate a single set of interface objects with no opportunity for the IDE or programmer to work around them, and irrespective of how much work was put into it most people would find that their programs break mark: i'm not sure i understand what you mean, can you please explain more? do you mean that: currently a GUI application built for GTK2 'knows' that it is talking to GTK2 and can tweak things accordingly, likewise one built for Qt5 can do the same. but an application that has been built for both has no means (at the user-code level) of determining if it is talking to GTK2 or Qt5? or do you mean that programmers building a GUI application that supported both GTK2 and Qt5 would need to put in extra effort to test every aspect of their program against both GTK2 and Qt5? or do you mean something else? from what dave wrote: "Mode ?  Project->Options->Additions&Overrides.  Add a new build mode for every widget, then, in the grid line them up. Easy to see, hard to describe in words." https://forum.lazarus.freepascal.org/index.php/topic,73405.msg576721.h tml#msg576721 ... it sounds like i should be able to, with just a few clicks, generate ELF binaries for two or more widget sets. i followed his instructions, but unfortunately i get the following error message when compiling in the Lazarus IDE: Warning: linker: /usr/bin/ld: cannot find -lQt5Pas: No such file or directory project1.lpr(27,1) Error: Error while linking ... when selecting the 'Qt5' option, and when selecting the 'Qt' option: Warning: linker: /usr/bin/ld: cannot find -lQt4Pas: No such file or directory project1.lpr(27,1) Error: Error while linking the machine that produced the above results is running Linux Mint 22.2 (XFCE) x86-64, supported until April 2029; all my other computers run similar configurations, although the machine i am typing on right now runs a rather old version 19.3. how do i install Qt5 support? and/or Qt4 support? preferably in a way that does not break anything! if i can easily produce multiple ELF binaries, each for a different widget set, then i already have available a relatively 'clean' solution to merge these into a single binary than can select between widget sets at startup. cheers, rob   :-) ---------------------------------------------------------------------- marcov · 2026-02-19 12:27 Quote from: robert rozee on February 17, 2026, 11:13:57 pmQuote from: Martin_fr on February 17, 2026, 10:45:31 pmEven if someone started this fulltime now, it wouldn't be do-able in time. so instead we do what? just sit back and wait for there to be even less "time"? Do what about what? I assume debian and most other distros will, each in their own time switch to the most promising alternative as default, probably QT5 or 6, as Abou suggested in the above maillist.  IMHO there was a chance on that happening eventually even if the GTK2 deprecation hadn't happened. We have one binary distribution per distro-version combination now, and that remains so. The only downside is minority architectures and distros might need extra work to package the qtpas package. It is what it is however. Quoteor do we abandon GTK2? but as others have pointed out, we are living in 'times of transition', where the is no one widget set that can be assumed as available on all desktop installations. drop GTK2 (as a pre-built Lazarus IDE) in favour of Qt5 and suddenly a whole lot of Linux desktops will be excluded. Why would those be excluded?  Anyway, as availability of gtk2 in the distros winds down, probably so will interest to continue develop and ship Lazarus with it till it eventually dies. Roughly like GTK1 before it. From what I heard the real trouble is that GTK3 and later are not so much a logic successor of GTK2 because of two reasons: Bug tickets for functionality not stressed for Gnome and the few other core distribution applications were closed randomly by GTK team without resolution.The primary Gnome (settings) clients switched to a more web like rendering model to render to fit width, and if height didn't match, show a slider. This invalidates many Lazarus applications more fixed screen orientated widget placement Those two make that other applications are different from Lazarus, and fixes necessarily for Lazarus somewhat more precise rendering requirements and placing options are not stressed, and the widgetset doesn't advance much in that regard. Some of this probably has to do with HIGHDPI getting more traction, and fixed size screen have a certain font size built in, and I can assume for very widely used applications (like Gnome Settings, but Windows 10+ settings also follow that model) that is better, but for many applications a fixed screen that only caters to a limited range font scaling, fthat is a reasonable assumption and saves a lot of scrolling. I heard those two issues from multiple sides around the 2013-2016 period, I however don't know in how far that is still the case (and similarly for GTK4, which only just started at the end of that period) ---------------------------------------------------------------------- marcov · 2026-02-19 12:34 Quote from: Thaddy on February 19, 2026, 12:26:30 pmTwo things: 1. Linux users prefer to install from their distro's repository. We have no insight in those installs The subthread was about a Lazarus which dynamically adapts to widgetset. Those most likely would not be in distro's repositories, as it is about circumventing the need for distro specific versions in the first place. (the multi widgetset dynloaded Lazarus is not very practical wrt cost/benefit IMHO, too much rowing against the stream and thus too much work. But others already pointed that out) Quote2. Many Linux users prefer to build from source, either the documented proper way or the convenient fpcupdeluxe way. And those also wouldn't use custom multi widget pre built binaries, so both arguments wouldn't change the number of users left over to run such downloaded universal Lazarus ELF binary, even if Robert's numbers were wrong. So I don't know why you reply to me. Maybe you meant to reply to Robert's original statement? ---------------------------------------------------------------------- PascalDragon · 2026-02-19 20:30 Quote from: robert rozee on February 17, 2026, 10:22:34 pmQuote from: PascalDragon on February 17, 2026, 08:52:36 pmWhile technically possible does not mean that it's feasible. For the LCL it simply is not worth the effort this would require. PascalDragon: are you also one of the Lazarus developers? i thought you were on 'team FPC'. Being “Team FPC” does not mean that I never worked inside the LCL. I have hunted the one or other issue inside it and thus I have a rough overview how it is structured internally. Quote from: robert rozee on February 17, 2026, 11:13:57 pmassuming the desire is to still ship a Lazarus IDE ELF/Linux binary for AMD64, the alternative is to embrace there being multiple 'sub-versions' of the IDE's binary: Lazarus IDE built for GTK2Lazarus IDE built for Qt5Lazarus IDE built for Qt6 The Debian packages are generated by the Debian package maintainer from source so it would be absolutely no problem for them to generate the IDE in a Qt variant if they'd be willing. ---------------------------------------------------------------------- dbannon · 2026-02-20 01:56 Quote from: robert rozee on February 19, 2026, 01:20:13 pm Did you look at https://wiki.freepascal.org/Qt5_Interface ? Warning: linker: /usr/bin/ld: cannot find -lQt5Pas: No such file or directory project1.lpr(27,1) Error: Error while linking As the error message stated, the linker (ld) cannot find a library. Newer distributions just need to install libqt5pas-dev which brings in the Qt5 libraries (~50M in unlikely the extreme you have none installed, by comparison, gtk2 is about 200M).  I suggest you don't use Qt4. Qt6 may well be a better choice. Quotethe machine that produced the above results is running Linux Mint 22.2 (XFCE) x86-64, supported until April 2029 Linux Mint 22.2 is based on Ubuntu 24.04 and therefore has up to date libqt5pas-dev. So, just install from your repo. Older systems may not have a suitable version of libq5pa-dev available, build them yourself or download from https://github.com/davidbannon/libqt5pas Its worth noting that the term "supported" when applied to Linux Distros is often misunderstood. It does not mean that the distro has all the up to date software available, just some selected (by distro maintainers) packages, often just security. If its an old distro release, it has old software. Davo ---------------------------------------------------------------------- vfclists · 2026-02-20 02:14 Quote from: robert rozee on February 19, 2026, 01:20:13 pmQuote from: MarkMLl on February 18, 2026, 09:13:31 am[...] What /is/ relevant is that it would mandate a single set of interface objects with no opportunity for the IDE or programmer to work around them, and irrespective of how much work was put into it most people would find that their programs break mark: i'm not sure i understand what you mean, can you please explain more? do you mean that: currently a GUI application built for GTK2 'knows' that it is talking to GTK2 and can tweak things accordingly, likewise one built for Qt5 can do the same. but an application that has been built for both has no means (at the user-code level) of determining if it is talking to GTK2 or Qt5? or do you mean that programmers building a GUI application that supported both GTK2 and Qt5 would need to put in extra effort to test every aspect of their program against both GTK2 and Qt5? or do you mean something else? from what dave wrote: "Mode ?  Project->Options->Additions&Overrides.  Add a new build mode for every widget, then, in the grid line them up. Easy to see, hard to describe in words." https://forum.lazarus.freepascal.org/index.php/topic,73405.msg576721.h tml#msg576721 ... it sounds like i should be able to, with just a few clicks, generate ELF binaries for two or more widget sets. i followed his instructions, but unfortunately i get the following error message when compiling in the Lazarus IDE: Warning: linker: /usr/bin/ld: cannot find -lQt5Pas: No such file or directory project1.lpr(27,1) Error: Error while linking ... when selecting the 'Qt5' option, and when selecting the 'Qt' option: Warning: linker: /usr/bin/ld: cannot find -lQt4Pas: No such file or directory project1.lpr(27,1) Error: Error while linking the machine that produced the above results is running Linux Mint 22.2 (XFCE) x86-64, supported until April 2029; all my other computers run similar configurations, although the machine i am typing on right now runs a rather old version 19.3. how do i install Qt5 support? and/or Qt4 support? preferably in a way that does not break anything! if i can easily produce multiple ELF binaries, each for a different widget set, then i already have available a relatively 'clean' solution to merge these into a single binary than can select between widget sets at startup. cheers, rob   :-) https://github.com/davidbannon/libqt6pas https://github.com/davidbannon/libqt5pas libqt4pas is quite old but some distros have ready built packages for it. https://wiki.lazarus.freepascal.org/Qt_Interface#Qt_4_Bindings https://wiki.lazarus.freepascal.org/Qt5_Interface Some distros have ready made packages for it. Another thing you have to remember is that when you compile LCL libraries, you have to adjust the output paths for the packages to include widgetset, OS, and architecture or else you will be in a whole world of pain as you switch between the widgetsets. PS. I see @dbannon responded as I was composing this reply. His answer may be more authoritative. ---------------------------------------------------------------------- robert rozee · 2026-02-21 14:20 am deviating further off topic i fear... just installing the following worked: sudo apt install libqt5pas-dev for the project i then tested (around 5000 lines of code), the only code change i needed to make was in one place where i had a TLabel that had multiple lines of text being assigned to it, with lines separated by carriage returns. i needed to change the carriage returns to carriage return + line feed, as just carriage returns alone were ignored by Qt5. however, i couldn't figure out any simple apt install for Qt6, and this page: https://wiki.freepascal.org/Qt6_Interface#Linux suggests that Qt6 is not entirely bug-free. does Qt6 provide backward compatibility with Qt5? ie, will a machine with Qt6 on it be likely to also have Qt5 present, or a Qt5 'compatibility layer'? another question - at the moment, if i give someone an ELF binary built for GTK2 they can (based on feedback i've received) just run it without any problems - they do not need to install anything else. does the same hold for an ELF binary i've built for Qt5? or do i also need to have them install libqt5pas.so? or is libqt5pas.so always present in distros that out-of-the-box have Qt5 installed? and lastly - how do i configure the Lazarus IDE to build multiple ELF binaries using different widget sets, without my needing to go into Project -> Options and change build mode manually? can one build mode be set up to do this? if i set up two lines in a mode, with both 'ticked', it only seems to use one of them (see below image). ideally, i'd like to be able to have, for example, building Project1 to produce two ELF images called Project1.GTK2 and Project1.Qt5. is this possible? cheers, rob   :-) ---------------------------------------------------------------------- Thaddy · 2026-02-21 15:35 Don't use Qt5, use Qt6. (Djeez, bad advice again Robert) Otherwise you are again on the backfoot by installing/migrating to something that is too old in the general perspective of things. Use Qt6. That's the thing that avoids your Wayland issues. Use Qt6, Use Qt6, Use Qt6. Stop promoting anything else. All experts agree about that. The rest is either too old on its own (GTK3) or does not work well with Wayland (Qt5) Feel free to use anything else of course, but than you are stuck with legacy or soon to be legacy. You may examine the list of software that Debian actually removes and that list is quite long, not just Lazarus/fpc. It is the longest list of removals I have seen yet with Debian. ---------------------------------------------------------------------- wp · 2026-02-21 17:25 Quote from: Thaddy on February 21, 2026, 04:35:08 pmUse Qt6. That's the thing that avoids your Wayland issues. Joking? This is a screenshot taken from Laz/QT6 on Majaro KDE/wayland. ---------------------------------------------------------------------- dsiders · 2026-02-21 17:30 Quote from: wp on February 21, 2026, 06:25:43 pmQuote from: Thaddy on February 21, 2026, 04:35:08 pmUse Qt6. That's the thing that avoids your Wayland issues. Joking? This is a screenshot taken from Laz/QT6 on Majaro KDE/wayland. A perfect example of a protocol designed by a committee that performs no implementations. ---------------------------------------------------------------------- sfeinst · 2026-02-21 19:18 Quote from: wp on February 21, 2026, 06:25:43 pmJoking? This is a screenshot taken from Laz/QT6 on Majaro KDE/wayland. Same issue with Debian Trixie.  To get around that, I installed anchordockingdsgn (which I never use normally) to get around all the centered IDE windows. ---------------------------------------------------------------------- Thaddy · 2026-02-21 20:01 Quote from: wp on February 21, 2026, 06:25:43 pmQuote from: Thaddy on February 21, 2026, 04:35:08 pmUse Qt6. That's the thing that avoids your Wayland issues. Joking? This is a screenshot taken from Laz/QT6 on Majaro KDE/wayland. Did not test KDE desktop, only trixies default. ---------------------------------------------------------------------- zeljko · 2026-02-22 20:58 Quote from: wp on February 21, 2026, 06:25:43 pmQuote from: Thaddy on February 21, 2026, 04:35:08 pmUse Qt6. That's the thing that avoids your Wayland issues. Joking? This is a screenshot taken from Laz/QT6 on Majaro KDE/wayland. No joking. That's default wayland behaviour. KDE is doing some changes in that direction (remember postitions) , but setting position of window is no-no in wayland, and it'll probably never work. So I can see all your windows centered - exactly what wayland does. Try to use docked ide (even that have problems with wayland). ---------------------------------------------------------------------- dsiders · 2026-02-22 22:13 Quote from: zeljko on February 22, 2026, 09:58:37 pmQuote from: wp on February 21, 2026, 06:25:43 pmQuote from: Thaddy on February 21, 2026, 04:35:08 pmUse Qt6. That's the thing that avoids your Wayland issues. Joking? This is a screenshot taken from Laz/QT6 on Majaro KDE/wayland. No joking. That's default wayland behaviour. KDE is doing some changes in that direction (remember postitions) , but setting position of window is no-no in wayland, and it'll probably never work. So I can see all your windows centered - exactly what wayland does. Try to use docked ide (even that have problems with wayland). Everyone keeps repeating this... but no one seems to read or understand it. DON'T USE WAYLAND. IT'S BRAIN-DEAD. If your favorite distro forces you to use it... it's time to move on to another distro. ---------------------------------------------------------------------- dbannon · 2026-02-22 23:43 Quote from: dsiders on February 22, 2026, 11:13:33 pmEveryone keeps repeating this... but no one seems to read or understand it. DON'T USE WAYLAND. IT'S BRAIN-DEAD. If your favorite distro forces you to use it... it's time to move on to another distro. While I agree absolutely with the sentiment, the fact is that its already hard to avoid Wayland, and becoming more so. Firstly, Wayland is not a "distro by distro" decision, its a desktop thing. For example, Trixie Debian, if you install/use Gnome or KDE, you get Wayland. If you install, same disto, Mate Desktop, you get X11. Xfce has committed to a totally Wayland model, Enlightenment was an early Wayland convert. I don't know about Cinnamon, Budgie etc.  Over time, Distros will want to simplify their repos so, pressure is on the Desktops to "comply". They will almost certainly do so. The FPC/Lazarus community can choose to ignore Wayland but that will not do us any good at all, its happening. Davo ---------------------------------------------------------------------- dsiders · 2026-02-23 01:22 Quote from: dbannon on February 23, 2026, 12:43:38 amQuote from: dsiders on February 22, 2026, 11:13:33 pmEveryone keeps repeating this... but no one seems to read or understand it. DON'T USE WAYLAND. IT'S BRAIN-DEAD. If your favorite distro forces you to use it... it's time to move on to another distro. While I agree absolutely with the sentiment, the fact is that its already hard to avoid Wayland, and becoming more so. Firstly, Wayland is not a "distro by distro" decision, its a desktop thing. For example, Trixie Debian, if you install/use Gnome or KDE, you get Wayland. If you install, same disto, Mate Desktop, you get X11. OK, what I should had written is "if your favorite WM/DE...". It doesn't change the fact that distros are in fact dropping X11 by default... and both the distros and the desktops are shooting themselves in the foot. Quote from: dbannon on February 23, 2026, 12:43:38 amXfce has committed to a totally Wayland model, ... Good for them. I can now conveniently ignore them too. Quote from: dbannon on February 23, 2026, 12:43:38 amEnlightenment was an early Wayland convert. I bet both of its users are entirely happy too. Quote from: dbannon on February 23, 2026, 12:43:38 am I don't know about Cinnamon, Budgie etc.  Do they have users? Seriously, who cares? Quote from: dbannon on February 23, 2026, 12:43:38 amOver time, Distros will want to simplify their repos so, pressure is on the Desktops to "comply". They will almost certainly do so. The FPC/Lazarus community can choose to ignore Wayland but that will not do us any good at all, its happening. Ok, let's ratchet up our anxiety level and fret. What can Lazarus do about Wayland being brain-dead? Nothing. Ignore it until the time that they: A) Admit they were stupid and fucked up royally. B) Have fixed it. I have pretty much the same outlook on this Debian drops Lazarus hysteria. Let's suppose they do it... does that mean Debian users cannot install Lazarus? No, it does not. Does it mean that the Debian nonsense about repos goes away? I hope so... and YEAH. ---------------------------------------------------------------------- cdbc · 2026-02-23 07:09 Hi AFAIK @Graeme is __not__ in a hurry, to jump on the 'Wayland Bus' anytime soon  I'm wholeheartedly exploring 'fpGUI' ...and having fun doing it  at the moment -- I guess that's my path forward. Just my 2 cents worth N.b.: I do love my Qt6, though, but atst. I'm also exploring 'IceWM'  Regards Benny ---------------------------------------------------------------------- PascalDragon · 2026-02-23 20:41 Quote from: wp on February 21, 2026, 06:25:43 pmQuote from: Thaddy on February 21, 2026, 04:35:08 pmUse Qt6. That's the thing that avoids your Wayland issues. Joking? This is a screenshot taken from Laz/QT6 on Majaro KDE/wayland. That's not a fault of Qt and GTK would behave the same, because Wayland did not provide a way to specify positions until a few weeks ago and even then it's only part of the protocols for now, so essentially no released compositor and no released framework supports it. Quote from: zeljko on February 22, 2026, 09:58:37 pmNo joking. That's default wayland behaviour. KDE is doing some changes in that direction (remember postitions) , but setting position of window is no-no in wayland, and it'll probably never work. So I can see all your windows centered - exactly what wayland does. As said above, initial positioning is the point of the xx-zones protocol. And remembering positions is supposed to be handled by the yet-to-be-merged session restore protocol. ---------------------------------------------------------------------- zeljko · 2026-02-25 07:29 + current distros probably will never update to such wayland addons (eg KDE Plasma 6.6). ---------------------------------------------------------------------- Zvoni · 2026-02-25 08:22 Quote from: dbannon on February 23, 2026, 12:43:38 am Xfce has committed to a totally Wayland model, Enlightenment was an early Wayland convert. I don't know about Cinnamon, Budgie etc.  Cinnamon has declared Wayland as "experimental" Have a guess what they use as Display-Server.... QuoteQuote from: dbannon on 23-02-2026, 00:43:38     I don't know about Cinnamon, Budgie etc. Do they have users? Seriously, who cares?Considering Cinnamon is the Standard DE for Linux Mint, and Mint is one of the most used Ubuntu- derivatives.... ---------------------------------------------------------------------- dbannon · 2026-02-25 09:49 Quote from: PascalDragon on February 23, 2026, 09:41:26 pm.... because Wayland did not provide a way to specify positions until a few weeks ago and even then it's only part of the protocols for now, so essentially no released compositor and no released framework supports it. Further, I get the impression that this xx-zones is 'controversial', the Wayland Puritans publicly hate it. I don't understand that attitude but ignoring it will not help ! I just don't understand why positioning on screen is offensive to some people ?? Davo ---------------------------------------------------------------------- lproven · 2026-02-25 11:05 Quote from: dbannon on February 06, 2026, 04:52:29 amThis is because they are dropping support for gtk2 and both FPC and Lazarus (appear) to depend on the much out of date gtk2 ! FPC is not alone with this problem. Multiple other programs in Debian use Gtk2 as well -- a partial list (in English, despite the URL) is here: https://prohoster.info/en/blog/novosti-interneta/v-debian-14-namereny- prekratit-postavku-gtk2 The Ardour digital audio workstation is in active development -- the project recently released Ardour 9.2 -- and it still uses Gtk2: https://ardour.org/faq.html#toolkit As a result, the Ardour team is maintaining its own fork of Gtk2 called Ytk. Perhaps it would be possible, as a first step, to switch to Ytk instead? That would be a quick fix, while a more complete or thorough one is investigated. ---------------------------------------------------------------------- dbannon · 2026-02-26 00:33 Quote from: lproven on February 25, 2026, 12:05:20 pm... Perhaps it would be possible, as a first step, to switch to Ytk instead? That would be a quick fix, while a more complete or thorough one is investigated. While thanks for the suggestion, no, I really don't think that would be good for FPC/Lazarus. Truth is we are not really dependent on gtk2. We could easily use Qt5 or Qt6 right now and Gtk3 is not too bad already. There are, IMHO, two issues - An apparent but not real dependency in FPC on gtk2. FPC has a dir, /packages/gtk2 that as some gtk2 and other libary bindings that, unfortunately Debian assumes was some gtk2 build dependency. Its not and never was. That has been fixed, sort of. Lazarus keeps shipping, in its own official packages,  gtk2 product. That sends a signal that Lazarus is dependent on gtk2, only makes gtk2 apps, needs gtk2 to run and so on. Again, wrong, Lazarus can, on *nix, use and make Qt5. Qt6 and, almost, gtk3. In both cases, political not technical. The relevant bodies need to review certain decisions. Lazarus could, as a first step, move the libpango and libpangocairo bindings out of its gtk3 tree and into somewhere more (*nix) general because Qt5 and Qt6 apps need them, currently they use the ones that exist in that FPC gtk2 directory that is upsetting Debian so much. Davo ---------------------------------------------------------------------- Thaddy · 2026-02-26 09:14 @dbannon A good write up except I would not mention neither Qt5 nor GTK3 as possible solutions. Both are already too old in the scheme of things. For the short term I would concentrate on a Qt6 build for Lazarus and repackaging as per your analysis for both FPC and Lazarus. The FPC repackaging should be in 3.2.4. if possible in this case. (port and a back-port) Qt5 and GTK3 carries the risk of development investment in widgetsets that most already consider legacy. An important side note is PascalDragon's remark about the recent protocol definition in Wayland that should finally handle old style windowed interfaces. ---------------------------------------------------------------------- Fred vS · 2026-02-26 12:56 Quote from: Thaddy on February 26, 2026, 10:14:15 amAn important side note is PascalDragon's remark about the recent protocol definition in Wayland that should finally handle old style windowed interfaces. Great, that's all that's left to fix: https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277 ---------------------------------------------------------------------- vfclists · 2026-02-26 14:26 Smile  This topic made it to Hacker News - https://news.ycombinator.com/item?id=47149582 ---------------------------------------------------------------------- PascalDragon · 2026-02-26 20:43 Quote from: Thaddy on February 26, 2026, 10:14:15 amFor the short term I would concentrate on a Qt6 build for Lazarus and repackaging as per your analysis for both FPC and Lazarus. The problem with Qt is that an additional dependency is required in the form of the qtXpas library. Quote from: Thaddy on February 26, 2026, 10:14:15 amThe FPC repackaging should be in 3.2.4. if possible in this case. (port and a back-port) There will be no repackaging. Quote from: Thaddy on February 26, 2026, 10:14:15 amAn important side note is PascalDragon's remark about the recent protocol definition in Wayland that should finally handle old style windowed interfaces. I'll only believe that when major compositors implement that protocol. ---------------------------------------------------------------------- zeljko · 2026-02-26 22:18 Quote from: PascalDragon on February 26, 2026, 09:43:06 pm The problem with Qt is that an additional dependency is required in the form of the qtXpas library. Distro have such package, I don't see any problem because of libQtXPas dependency. It is better to have a sparrow in your hand than a dove on a branch. ---------------------------------------------------------------------- dbannon · 2026-02-27 01:54 Quote from: zeljko on February 26, 2026, 11:18:04 pmDistro have such package, I don't see any problem because of libQtXPas dependency. It is better to have a sparrow in your hand than a dove on a branch. They do indeed but its not quite a simple as that. If you, the developer, are using a newer distro and you don't plan to distribute working binaries, it is that simple. But that is not usually the case. If you have customers or users that might be using a different distro or a different aged distro, problems. Lets take Ubuntu of example, I don't use Ubuntu but its version numbers help this discussion because they define its release date. The most recent (LTS) Ubunu is 24.04, it has usable libqt5pas and libqt6pas in its repo. Works fine.The previous 22.04 does not have usable libqt5pas nor any libqt6pas. Can be built and runs fine.The 20.04 Ubuntu has neither, a built libqt5pas can be built and works, libqt6pas cannot. Now, U20.04 became unsupported last year but is still covered by various Ubuntu Pro plans until, wait for it, 2035 ! The problem is worse with Debian and its direct derivatives, a slightly slower release cycle. I use Debian bookworm, under LTS until 2028. It has libqt5pas 2.6+2.0.8+dfsg-2, no libqt6pas. That libqt5pas will not work with apps made using current Lazarus. A new one, and a libqt6pas can be built and work fine. Remember please that a major proportion of Linux distros are derivatives, one way or another of Debian. End user do not cope well with these 'extras' ! Davo ---------------------------------------------------------------------- robert rozee · 2026-02-27 04:31 Quote from: dbannon on February 27, 2026, 02:54:22 amQuote from: zeljko on February 26, 2026, 11:18:04 pmDistro have such package, I don't see any problem because of libQtXPas dependency. It is better to have a sparrow in your hand than a dove on a branch. [...] The most recent (LTS) Ubunu is 24.04, it has usable libqt5pas and libqt6pas in its repo. Works fine.The previous 22.04 does not have usable libqt5pas nor any libqt6pas. Can be built and runs fine.The 20.04 Ubuntu has neither, a built libqt5pas can be built and works, libqt6pas cannot.[...] The problem is worse with Debian and its direct derivatives, a slightly slower release cycle. I use Debian bookworm, under LTS until 2028. It has libqt5pas 2.6+2.0.8+dfsg-2, no libqt6pas. That libqt5pas will not work with apps made using current Lazarus. A new one, and a libqt6pas can be built and work fine. [...] End user do not cope well with these 'extras' ! many thanks Davo, you have answered some of the questions i asked back in Reply #77: Quote from: robert rozee on February 21, 2026, 03:20:04 pm[...] does Qt6 provide backward compatibility with Qt5? ie, will a machine with Qt6 on it be likely to also have Qt5 present, or a Qt5 'compatibility layer'? another question - at the moment, if i give someone an ELF binary built for GTK2 they can (based on feedback i've received) just run it without any problems - they do not need to install anything else. does the same hold for an ELF binary i've built for Qt5? or do i also need to have them install libqt5pas.so? or is libqt5pas.so always present in distros that out-of-the-box have Qt5 installed? [...] for me, this renders supporting Qt/Qt5/Qt6 of absolutely NO use. my users expect to be sent an ELF binary that just works, without need for any installation process. they lack the ability to determine if extra libraries are installed or to go on to find and install them; as it is they can only just manage to flag a binary as being executable! why can the functionality provided by libQt5pas.so and/or libQt6pas.so not be compiled into an application's ELF binary? cheers, rob   :-( ---------------------------------------------------------------------- AmatCoder · 2026-02-27 06:46 Maybe I am missing something but you can build libQt6Pas statically... ---------------------------------------------------------------------- zeljko · 2026-02-27 07:30 For static library usage you must buy Qt license AFAIR. ---------------------------------------------------------------------- MarkMLl · 2026-02-27 07:50 Quote from: dbannon on February 27, 2026, 02:54:22 amQuote from: zeljko on February 26, 2026, 11:18:04 pmDistro have such package, I don't see any problem because of libQtXPas dependency. It is better to have a sparrow in your hand than a dove on a branch. They do indeed but its not quite a simple as that. If you, the developer, are using a newer distro and you don't plan to distribute working binaries, it is that simple. But that is not usually the case. If you have customers or users that might be using a different distro or a different aged distro, problems. Lets take Ubuntu of example, I don't use Ubuntu but its version numbers help this discussion because they define its release date. There is also an issue in that the shim library is only good for a certain range of Lazarus versions. If a developer compiles up a (fairly wide) range for application testing, at some point compatibility between the LCL and libQt#Pas breaks and neither the IDE nor applications will work with Qt. These days it's obviously possible to work round that using some form of container, but it's unfortunate and argues against libQt#Pas being a panacea. MarkMLl ---------------------------------------------------------------------- Handoko · 2026-02-27 07:51 Qt Community Edition is only for open source projects, or you have to purchase the license. I've just checked the price, the license for small business is $ 618 per year. ---------------------------------------------------------------------- marcov · 2026-02-27 08:05 Quote from: MarkMLl on February 27, 2026, 08:50:37 amThere is also an issue in that the shim library is only good for a certain range of Lazarus versions. If a developer compiles up a (fairly wide) range for application testing, at some point compatibility between the LCL and libQt#Pas breaks and neither the IDE nor applications will work with Qt. If QT becomes more mainstream, there is probably also more room for distro-version qtpas maintenance. Unfortunately that is a Linux/*nix reality that you can't escape. There is no such thing as universal binaries. ---------------------------------------------------------------------- AmatCoder · 2026-02-27 08:48 Quote from: AmatCoder on February 27, 2026, 07:46:41 amMaybe I am missing something but you can build libQt6Pas statically... Quote from: zeljko on February 27, 2026, 08:30:45 amFor static library usage you must buy Qt license AFAIR. I was talking about to build only libQt6Pas statically. It has a LGPL linking exception license. So you can easily distribute binary (Qt6Core, Qt6Gui, Qt6Widgets libs still must be supplied by distros). ---------------------------------------------------------------------- zeljko · 2026-02-27 08:54 So, how do you plan to build libQt6Pas statically without static Qt6 libs ? ---------------------------------------------------------------------- AmatCoder · 2026-02-27 09:10 You don't need static Qt6 libs to build libQt6Pas statically. Into lcl/interfaces/qt6/cbindings: Code: [Select]qmake6 make staticlib It will build an libQt6Pas.a archive. ---------------------------------------------------------------------- dbannon · 2026-02-27 09:39 Quote from: robert rozee on February 27, 2026, 05:31:48 am... my users expect to be sent an ELF binary that just works, without need for any installation process. they lack the ability to determine if extra libraries are installed or to go on to find and install them; as it is they can only just manage to flag a binary as being executable! Hmm, thats why we have packages. Almost any app has some dependencies, tomboy-ng in gtk2 form often needs libnotify for example.  Just shipping a binary and asking end users to put it somewhere appropriate sounds like a very bad approach. Linux packages, generally debs, rpms or paks include a list of dependencies, license files, maybe a man page, config files and defines where all those files, including the binaries, need to go. Quotewhy can the functionality provided by libQt5pas.so and/or libQt6pas.so not be compiled into an application's ELF binary? I suspect it could be possible, compile to a .a file, link statically. Then rely on the applications package to define the Qt5 or Qt6 libraries needed as dependencies. Robert, you should perhaps consider AppImage, SNAP or Flatpack approach ?  You could then ship a gtk2 environment along with your binary.  eg https://wiki.freepascal.org/AppImage_Packaging Davo ---------------------------------------------------------------------- dbannon · 2026-02-27 12:27 OK, the news is that the Debian Pascal Devs have now pushed a Lazarus 4.6 Qt5 package (or bunch of packages, sigh... ) to Debian Experimental. While I would have rathered Qt6, at least we will have a Lazarus in Forky and we can expect the other FPC/Lazarus apps (including mine) will not be removed. Davo ---------------------------------------------------------------------- robert rozee · 2026-02-27 12:30 Quote from: dbannon on February 27, 2026, 10:39:04 am[...] Hmm, thats why we have packages. Almost any app has some dependencies, tomboy-ng in gtk2 form often needs libnotify for example.  Just shipping a binary and asking end users to put it somewhere appropriate sounds like a very bad approach. Linux packages, generally debs, rpms or paks include a list of dependencies, license files, maybe a man page, config files and defines where all those files, including the binaries, need to go. my users, and i, have absolutely zero interest in any of that. one ELF binary that the user can place wherever they want that can be double- clicked on from the desktop and will run. no installation required, no man page, no licenses, a single config file placed in ~/.config out of harm's way. to date, this approach has worked well and i have had few (actually none) complaints. Quote from: dbannon on February 27, 2026, 10:39:04 amQuotewhy can the functionality provided by libQt5pas.so and/or libQt6pas.so not be compiled into an application's ELF binary? I suspect it could be possible, compile to a .a file, link statically. Then rely on the applications package to define the Qt5 or Qt6 libraries needed as dependencies. it looks like libQt5Pas.so.1.2.15 (64-bit AMD64) is around 2.6mb in size. i can live with that being bound into my application. what versions of Qt5 installation will this not work for? Quote from: dbannon on February 27, 2026, 10:39:04 amRobert, you should perhaps consider AppImage, SNAP or Flatpack approach ?  You could then ship a gtk2 environment along with your binary.  eg https://wiki.freepascal.org/AppImage_Packaging not happening. if it gets to that ridiculous point i'll abandon distributing for Linux and just do win32 versions, tell anyone who needs a Linux version that they are on their own or need to use a winXP VM (or wine). there is a point at which developing for a platform becomes too much trouble - especially a platform that is down at 5% market share. cheers, rob   :-( ---------------------------------------------------------------------- marcov · 2026-02-27 14:41 Moderator notice: Since this thread has Lazarus in the subject, I split of the side threads of fpgui and msegui in their own thread, as they could be considered off-topic in this thread. ---------------------------------------------------------------------- vfclists · 2026-02-28 17:40 Quote from: robert rozee on February 27, 2026, 01:30:14 pm there is a point at which developing for a platform becomes too much trouble - especially a platform that is down at 5% market share. cheers, rob   :-( What is the name of your application? Do you have more than one? ---------------------------------------------------------------------- PascalDragon · 2026-02-28 17:59 Quote from: robert rozee on February 27, 2026, 05:31:48 amfor me, this renders supporting Qt/Qt5/Qt6 of absolutely NO use. my users expect to be sent an ELF binary that just works, without need for any installation process. they lack the ability to determine if extra libraries are installed or to go on to find and install them; as it is they can only just manage to flag a binary as being executable! You can have the same problem with GTK. If you use a Qt based KDE distribution it can be possible that no GTK at all is installed there. The only solution for this is if you statically link in everything or if you use a custom widgetset that directly sits atop X11 or Wayland. Quote from: robert rozee on February 27, 2026, 05:31:48 amwhy can the functionality provided by libQt5pas.so and/or libQt6pas.so not be compiled into an application's ELF binary? As others mentioned, you can, but then you need to pay the company that develops Qt to keep your application proprietary. ---------------------------------------------------------------------- inky · 2026-03-01 00:28 i think considering gtk or qt (any versions) as future of the lazarus project was a mistake since the beginning. we had many years while gtk2 was alive to make msegui and/or custowdrawn actually usable with lcl. msegui lcl code is currrently broken, doesn't compile other way is adapting lcl each time for newer gtk or newer qt. and this strong dependence  on them. ---------------------------------------------------------------------- robert rozee · 2026-03-01 01:27 Quote from: PascalDragon on February 28, 2026, 06:59:18 pmQuote from: robert rozee on February 27, 2026, 05:31:48 amwhy can the functionality provided by libQt5pas.so and/or libQt6pas.so not be compiled into an application's ELF binary? As others mentioned, you can, but then you need to pay the company that develops Qt to keep your application proprietary. and you honestly believe that using a 'shim' library makes any legal difference?! did someone get any legal advice on this matter - from a real lawyer? aside from the fact that i don't keep any source code secret, i can see no way the "owners" of Qt could take action against someone calling their library routines directly (sans any shim). no one is talking about including Qt code within their FPC/Lazarus project, merely making calls directly to Qt's .so libraries in the same way applications make calls to glibc library routines. if the owners of Qt had a leg to stand on, then Microsoft would likewise be able to demand payment from every software author who wrote a windows applications that called a windows DLL's. btw, i agree with inky wholeheartedly; years ago the FPC/Lazarus developers should have put their (linux) efforts towards a long-term solution that did not depend on the fate of (what turns out to be) an ever-changing collection of widget sets. talking directly to X11 would - in retrospect - make far more sense. cheers, rob. ---------------------------------------------------------------------- 440bx · 2026-03-01 04:03 Quote from: robert rozee on March 01, 2026, 02:27:22 amyears ago the FPC/Lazarus developers should have put their (linux) efforts towards a long-term solution that did not depend on the fate of (what turns out to be) an ever-changing collection of widget sets. talking directly to X11 would - in retrospect - make far more sense. Are you saying that the Lazarus developers should have developed their own widget set ?  (that's what the above statement sounds like.) ---------------------------------------------------------------------- robert rozee · 2026-03-01 04:20 Quote from: 440bx on March 01, 2026, 05:03:38 amAre you saying that the Lazarus developers should have developed their own widget set ?  (that's what the above statement sounds like.) given the impending demise of GTK2 that others predict, the abandonment of development of GTK3 by the GTK developers before it was even completed, i think it is sensible to label GTK as a poor project to pin one's hopes on. meanwhile, we are told by others on this thread that Qt supposedly has a set of onerous licensing requirements that prevent one making direct use of it's libraries, which for any open-source developer should be a major red flag against having anything to do with it. what else is there left? we have one dead widget set, one legally toxic widget set, and a few obscure dribs-and-drabs that according to some don't even compile. given the scale of the problem, it makes sense to (from the perspective of what we know today) to simply develop something that talks to X11 directly. it is not exactly rocket science, and surely far less complex than the path that has been followed down for the last couple of decades - trying to use GTK but having it fade from use, trying to switch over to Qt but having toxic legal barriers thrown up. and who is to say that Qt will not replaced by something different in the near future? X11 has been around for, what, 40 years or more? it has certainly survived the test of time. this wayland thing is all the rage now, but has its own set of problems. and people talk about Xwayland - is this wayland emulating X11? if so, then carrying on with X11 is just fine! cheers, rob   :-) ---------------------------------------------------------------------- 440bx · 2026-03-01 05:28 Quote from: robert rozee on March 01, 2026, 05:20:01 amgiven the scale of the problem, it makes sense to (from the perspective of what we know today) to simply develop something that talks to X11 directly. it is not exactly rocket science, and surely far less complex than the path that has been followed down for the last couple of decades - trying to use GTK but having it fade from use, trying to switch over to Qt but having toxic legal barriers thrown up. and who is to say that Qt will not replaced by something different in the near future? Your argument sounds sensible. My concern would be that an X11 widget set isn't what the Lazarus project is supposed to be about.  IOW, if a new/better X11 widget set is necessary for one reason or another, it should be a separate project that isn't necessarily associated with Lazarus, IOW, it should be "general", not perceived to be Lazarus specific. ---------------------------------------------------------------------- inky · 2026-03-01 06:52 440bx, there are already two pascal widgetsets available in lazarus. one is fpgui. it is a separate project, but lazarus has an lcl code to use it instead of gtk or qt: https://wiki.lazarus.freepascal.org/Roadmap readme in lcl/interfaces/fpgui describes how to use it with lazarus: copy its src directory to this lcl/interfaces/fpgui then in Project Options -> Compiler Options -> Additions and Overrides, choose LCLWidgetType: fpgui, and fpGUIPlatform: x11. right now that lcl code is abandoned and doesn't work: https://github.com/graemeg/fpGUI/issues/142 other effort is customdrawn backend, we even were able to generate android lcl apps with it. but it is also in bad state and android is not possible anymore, because probably, we have no funding, no resources, not enough people who would deal with it. i say 'we' as community, i am not a part of fpc or lazarus team. see the roadmap linked. then there's a third, already mentioned pascal toolkit: msegui, but that perhaps would be even harder to wrap for lazarus lcl and no effort was made so far https://wiki.freepascal.org/MSEide%2BMSEgui#But_what_about_Lazarus? delphi with their firemonkey widgets made something like customdrawn or fpgui but that actually works. they don't draw on x11 or win32 but get an opengl window from the os and draw on it. since it is possible to get opengl on anything, they can draw on android or ios as well. but i am not of course blaming anyone, delphi has lots of resources and is a proprietary commercial and very expensive project, and lazarus is driven by volounteers. still even delphi used fpc to compile to arm at some point. unfortunately x11 is also not written in stone: gtk5 dropped support for x11 and some corps allegedly force the transition from x11 to wayland. i personally dont see myself switching, and i even started on wrapping a WINGs widgetset to use it from pascal, to not depend on gtk. though probably instead i had to try to fix the linked lcl issue or use / contribute to fpgui or mseide. ---------------------------------------------------------------------- dbannon · 2026-03-01 07:27 Quote from: 440bx on March 01, 2026, 06:28:59 amMy concern would be that an X11 widget set isn't what the Lazarus project is supposed to be about.  IOW, if a new/better X11 widget set is necessary for one reason or another, it should be a separate project that isn't necessarily associated with Lazarus, IOW, it should be "general", not perceived to be Lazarus specific. OK, a new general Widget set ? That means, something of the scale of gtk2, gtk3, Qt6 or Qt6 (win32, Cocoa)?  Because thats what they are, general widget sets. How will one more widget set solve the problem ?  It will still need to be migrated to Wayland, as gtk3, Qt5 and Qt6 were (gtk2 being dropped by the wayside) and would still need the massive commitment to develop and maintain. Matters little whether its a new, stand alone widget set or a new layer on top of Lazarus, its still a massive task to build and maintain.  And it does not 'look' native to many end user's chagrin. Davo ---------------------------------------------------------------------- Ericounet · 2026-03-01 07:29 Gtk2 is outdated (even if it works fine). Maybe it's time to "upgrade" to Gtk4? ---------------------------------------------------------------------- robert rozee · 2026-03-01 07:39 Quote from: dbannon on March 01, 2026, 08:27:28 am[...] it does not 'look' native to many end user's chagrin. maybe that is just the price that has to be paid. cheers, rob   :-) ---------------------------------------------------------------------- ron.dunn · 2026-03-01 08:21 There are only two Linux desktops worthy of official support - GTK and QT. Anything else is a sideshow. Interesting, well-meaning, but completely out of date and irrelevant. Of those two desktops, QT is sullied by licensing and distribution issues. That really leaves GTK as the most strategic target. And since it also happens to be the most widely supported across distributions, and by user count, that's where FPC and Lazarus should focus. ---------------------------------------------------------------------- 440bx · 2026-03-01 08:29 Just in case, I'll clarify that I've been following this thread strictly driven by curiosity and, the post https://forum.lazarus.freepascal.org/index.php/topic,73405.msg577383.h tml#msg577383 seemed to suggest a Lazarus specific widget set would have been (would be ?) a better solution in the long run than the current situation.  That further peeked my curiosity. The really crucial thing I want to get at is, I do not have enough knowledge about Linux and the widget set situation in Linux to emit an opinion of any kind about the current situation. My participation is strictly to satisfy my curiosity and hopefully get a clearer picture than the one I have now (which is very foggy to say the least.) ---------------------------------------------------------------------- Thaddy · 2026-03-01 11:33 Just in case: Also don't fall into the GTK3 trap because that is also legacy. For new debvelopment use GTK4, although GTK3 is currently still supported. See https://gtk.org A choice for gtk -> gtk3 is like running backwards and should not even be considered. ---------------------------------------------------------------------- vfclists · 2026-03-01 12:17 How about Skia ie something based on its  Skia4delphi/ variant? https://wiki.freepascal.org/Skia Is it the kind of toolkit capable of building a widget around, like MSEGui or FPGui? ---------------------------------------------------------------------- marcov · 2026-03-01 12:25 Quote from: vfclists on March 01, 2026, 01:17:01 pmHow about Skia ie something based on its  Skia4delphi/ variant? https://wiki.freepascal.org/Skia Is it the kind of toolkit capable of building a widget around, like MSEGui or FPGui? Please keep MSEGui or FPGui to the split off thread. But I assume so, specially for fpgui, which seems designed to be owner drawn with minimal requirements. Same for the Lazarus ownerdrawn widgetset, if you are willing to work on that. ---------------------------------------------------------------------- Thaddy · 2026-03-01 12:42 Quote from: vfclists on March 01, 2026, 01:17:01 pmHow about Skia ie something based on its  Skia4delphi/ variant? Note the focus is about what Linux distributions offer as mainstream widgetsets (GTKx, Qtx) and underlying window compositors (X, Wayland). Focus on that: MAINSTREAM plz. There is no point in choosing anything else but mainstream technology for default releases. ---------------------------------------------------------------------- vfclists · 2026-03-01 12:45 Quote from: marcov on March 01, 2026, 01:25:05 pmQuote from: vfclists on March 01, 2026, 01:17:01 pmHow about Skia ie something based on its  Skia4delphi/ variant? https://wiki.freepascal.org/Skia Is it the kind of toolkit capable of building a widget around, like MSEGui or FPGui? Please keep MSEGui or FPGui to the split off thread. But I assume so, specially for fpgui, which seems designed to be owner drawn with minimal requirements. Same for the Lazarus ownerdrawn widgetset, if you are willing to work on that. I'm not speaking about MSEGui or FPGui as such, but whether if the Lazarus IDE was based on some custom graphics widgetset, a library like Skia would be a good option if it has all the necessary primitives, and will automatically work on all its supported platforms. ---------------------------------------------------------------------- robert rozee · 2026-03-01 13:23 Quote from: marcov on March 01, 2026, 01:25:05 pmPlease keep MSEGui or FPGui to the split off thread Quote from: Thaddy on March 01, 2026, 01:42:41 pmNote the focus is about what Linux distributions offer as mainstream widgetsets (GTKx, Qtx) and underlying window compositors (X, Wayland). Focus on that: MAINSTREAM as i pointed out earlier: we have one dead widget set (GTK2/3/etc), one legally toxic widget set (Qt5/6/etc), and a few obscure dribs-and- drabs that according to some don't even compile. neither of the two choices that we are 'allowed' to discuss (GTKx and Qtx) appear to be viable options going forward. in particular, it looks like there have been concerns about the implications of Qt's licensing model for quite some time - a summary from google reads: "Whether Qt’s licensing has "poisoned" the Linux desktop is a subject of ongoing debate within the free software community, characterized more by developer anxiety and strategic maneuvering than immediate destruction of the ecosystem. While Qt is undeniably one of the best toolkits for creating native-looking Linux applications (particularly within KDE), its dual-licensing model and past attempts to restrict Long Term Support (LTS) releases have created tension [...] In 2020, The Qt Company considered limiting new LTS releases to paid customers for the first 12 months. This was seen as a threat to the open-source community, prompting worries that free software would be stuck with buggy, older versions of the toolkit [...] The Qt legal restrictions have not "poisoned" the Linux desktop, but they have introduced a layer of fear and uncertainty [...] For most, Qt remains a powerful, and free option, but the licensing structure means developers must be cautious about how they use it, particularly if they intend to build commercial [software]"the above leaves me feeling that, at best, Qt should only ever be regarded as a '2nd option' made available as a backup to something else - be that GTK2/3/etc, MSEGui, FPGui or some other direct-to-X11 system. cheers, rob   :-) ---------------------------------------------------------------------- marcov · 2026-03-01 14:21 Quote from: vfclists on March 01, 2026, 01:45:32 pm I'm not speaking about MSEGui or FPGui as such, but whether if the Lazarus IDE was based on some custom graphics widgetset, a library like Skia would be a good option if it has all the necessary primitives, and will automatically work on all its supported platforms. It would still be non native controls. The controls don't change with the system skin or HiDPI settings, and often don't support OS specific non visual user experience like keyboard (tabbing, system level accelerator keys) and mouse navigation. Everything has to be hand added, and to be frank, that rarely happens, and user acceptance is low.  The only benefit seems to be their low dependencies. But that could be a lot better if applications wouldn't have to be rewritten, and they would implement the LCL, hence the mention of the customdrawn widgetset. Since it would be good to have a custom drawn as stopgap for new systems and other unforeseeable cases. But rewriting often is a bridge too far. If you are interested you could develop another one based on SKIA. Good luck. I however don't think this thread really isn't a good example of such unforeseeable case, as there is QT, and even GTK3 on the horizon. ---------------------------------------------------------------------- inky · 2026-03-01 14:31 perhaps ytk way indeed should be researched? https://www.phoronix.com/forums/forum/software/desktop- linux/1559516-ardour-digital-audio-workstation-drops-gtk-option-in- favor-of-its-ytk-fork ardour supports it. maybe it is an easiest way today to replace gtk2 with ytk? ---------------------------------------------------------------------- marcov · 2026-03-01 14:36 Quote from: robert rozee on March 01, 2026, 02:23:31 pmas i pointed out earlier: we have one dead widget set (GTK2/3/etc), one legally toxic widget set (Qt5/6/etc), and a few obscure dribs-and-drabs that according to some don't even compile. The problem with the Toxic designation is that is the hardline GNU interpretation of the GPL, that is not commonly shared.  Granted, I can't identify the old clause that was in the GPL2 iirc for delivered with OS libraries any more in the GPL3. A clause that defanged the toxic bit (as you would use the QT delivered with the OS and its package systems). But that might just because I only superficially looked, and not really deep into the matter any more. I even used QT4 heavily in the PowerPC OS X era, before the emergence of the COCOA widgetset and the deprecation of PPC macs. Quoteneither of the two choices that we are 'allowed' to discuss (GTKx and Qtx) appear to be viable options going forward. in particular, it looks like there have been concerns about the implications of Qt's licensing model for quite some time - a summary from google reads: "Whether Qt’s licensing has "poisoned" the Linux desktop is a subject of ongoing debate within the free software community, characterized more by developer anxiety and strategic maneuvering than immediate destruction of the ecosystem. While Qt is undeniably one of the best toolkits for creating native-looking Linux applications (particularly within KDE), its dual-licensing model and past attempts to restrict Long Term Support (LTS) releases have created tension [...] In 2020, The Qt Company considered limiting new LTS releases to paid customers for the first 12 months. This was seen as a threat to the open-source community, prompting worries that free software would be stuck with buggy, older versions of the toolkit [...] If I read that paragraph, I see Threats, opinions, "debate" , Anxiety and other smokescreens arguments, but no hard statement from somebody that is not parroting the FSF that there is a problem. QuoteThe Qt legal restrictions have not "poisoned" the Linux desktop, but they have introduced a layer of fear and uncertainty [...] For most, Qt remains a powerful, and free option, but the licensing structure means developers must be cautious about how they use it, particularly if they intend to build commercial [software]" I get from that that nothing is eternal, but currently we are good to go. So IMHO no problem. If it fails switch to win32/64 and use Wine, that is the benefit of the LCL. Quotethe above leaves me feeling that, at best, Qt should only ever be regarded as a '2nd option' made available as a backup to something else - be that GTK2/3/etc, MSEGui, FPGui or some other direct-to-X11 system. MSEGUI to my best knowledge never attempted VCL/LCL compatibility, and has been an one man isolate for most of its time, with weirdness as own code style guides etc. FPGUI tried working on a LCL widgetset but that stalled. Customdrawn widgetset also seems to have stalled. (which was a better principle IMHO than FPGUI, as it assumed to being the backend of an LCL/VCL interface implementation, rather than just a 3rd party standalone project recycled for that purpose).   These are all so far from maturity (compared to even what is there for GTK3) that they are not part of any sane schedule. So that leaves GTK3 and QT5/6. So seriously, without knowing your exact situation and requirements(e.g. if you deploy the Linux distro also and can circumvent the issues for a while), start with accepting that nothing is perfect or eternal on the make it up as you go OS that is Linux. Then I would switch to a QT for the time being, but try to start supporting GTK3 development as much as possible and keep wine as emergency backup solution.  And if you are professional and Linux GUI deployment is mostly an hobby since only a real small percentage of your business, consider simply cutting it (well, that is almost the same as the wine option anyway) ---------------------------------------------------------------------- Thaddy · 2026-03-01 17:20 If Qt was toxic it wouldn't be in Debian as standard. That may have (was indeed) been the case in the distant past. Also: drop Qt5 and Qt6 in the same sentence: Qt5 has Wayland issues on its own that are not fixed. Qt6 does not have these issues. There are still some things that GTK2 lovers want and are not yet there, like window positioning, but at least there is now a Wayland protocol extension on which that can be implemented. The focus should be strictly on GTK4, maybe GTK3 and Qt6, not 5. (Btw, Marcov, Wayland support for Wine is still incomplete, so not recommended even if it is officially released) ---------------------------------------------------------------------- marcov · 2026-03-01 21:32 Quote from: Thaddy on March 01, 2026, 06:20:11 pm(Btw, Marcov, Wayland support for Wine is still incomplete, so not recommended even if it is officially released) Thanks, good to know, but my point was more that it didn't require additional development effort. ---------------------------------------------------------------------- ron.dunn · 2026-03-01 21:42 @Thaddy I think you're making a mistake by promoting GTK4 at this time. GTK3 is the current production recommendation. In fact, GTK advises that GTK2 code first migrate to GTK3, it's easier, and later plan a migration to GTK4. I think this should be the strategic direction for Lazarus on Linux. It remains the most widely supported desktop platform without licensing issues. ---------------------------------------------------------------------- dbannon · 2026-03-02 06:34 Folks, I started this thread, in theory, should I have some say in where it goes ? Instead, a long lecture ! Firstly, I would like to stop anyone commenting here who has not, recently tested Lazarus with Gtk3 - OK ? There really is quite a lot being said that, IMHO, indicates posters are not familiar with Lazarus and its ability to use multiple widget sets. So, some facts - Its really easy to switch between widgets when making Lazarus apps on Linux.  You do not need to be using any particular widget to make an app with any particular (possibly different) widget. The Gnome people, who make gtk, gtk2 gtk3 and gtk4 'release' a product then continue to develop, change, alter it making creating the bindings and widget specific interface files very difficult until they decide it is done, finished, no more changes. Gtk2 hit that 'done' stage many year ago, in that time, a stable Lazarus interface developed. That is, between the time the Gnome Devs declared it 'done' and quite recently. Not that long ago, Gtk3 was declared 'done', suddenly, the Lazarus Devs had a stable target to aim at and the Gtk3 interface has improved enormously. When I do a release of my app, I make, for Linux Gtk2, Qt5 and Qt6 version, it takes very little extra time to spit out three packages (and soon, 4 packages) and I let my end users choose what they need. Linux apps should always be released as a package (deb, rpm, pacman, AppImage) so, honestly, resolving dependencies is not hard. So, lets stop this silly talk about having to 'choose' a widget set, we can choose them all ! For the official packages on SourceForge, I'd suggest gtk2 for older systems and Qt6 for newer ones. And, probably sooner rather than later, add gtk3 to that mix. Yes, by all means, lets start on Gtk4, but don't expect it to be ready to go for some time. Davo ---------------------------------------------------------------------- robert rozee · 2026-03-02 10:08 Quote from: dbannon on March 02, 2026, 07:34:29 am[...] Firstly, I would like to stop anyone commenting here who has not, recently tested Lazarus with Gtk3 [...] hi Dave,     just tried to build with GTK3, got the following results: Compile Project, Mode: Testing WS, Target: /home/user/pascal/GFXterm 2.1d/project1: Exit code 1, Errors: 1, Warnings: 2 Warning: linker: /usr/bin/ld: cannot find -lgtk-3: No such file or directory Warning: linker: /usr/bin/ld: cannot find -lgdk-3: No such file or directory project1.lpr(27,1) Error: Error while linking this was using LCL 3.6.0, FPC 3.2.2. what do i need to do to resolve the error? cheers, rob   :-) ---------------------------------------------------------------------- zeljko · 2026-03-02 10:21 You must use Lazarus trunk for gtk3, also install gtk3/gdk3 devel packages to fix linker errors. ---------------------------------------------------------------------- robert rozee · 2026-03-02 10:34 Quote from: zeljko on March 02, 2026, 11:21:27 amYou must use Lazarus trunk for gtk3 [...] well, that excludes me from further discussions then - i only run the Lazarus packages downloadable from Sourceforge. i had rather hoped that Dave would reply that i just needed a newer LCL version: as well as the 3.6 i use, i see Sourceforge also has packages for 3.8, 4.0, 4.2, 4.4, and 4.6: https://sourceforge.net/projects/lazarus/files/Lazarus%20Linux%20amd64 %20DEB/ so long, and thanks for all the fish. rob   :-) ---------------------------------------------------------------------- dbannon · 2026-03-02 10:49 Quote from: zeljko on March 02, 2026, 11:21:27 amYou must use Lazarus trunk for gtk3, also install gtk3/gdk3 devel packages to fix linker errors. Yeah, I guess I should have said that. Sigh. You need to be using the Lazarus Main (aka trunk, master etc) as it has all the new gtk3 content. And if you are running a deb based system, you need to install the package libgtk-3-dev on your system (but not needed on end user system). Not sure what the RPM version is called, Arch do not need -dev packages. zeljko has been doing some great work, I reckon he needs people to test it. We'd all like to see it in Lazarus 5.0 ! Davo ---------------------------------------------------------------------- PascalDragon · 2026-03-02 20:43 Quote from: robert rozee on March 02, 2026, 11:34:39 ami had rather hoped that Dave would reply that i just needed a newer LCL version: as well as the 3.6 i use, i see Sourceforge also has packages for 3.8, 4.0, 4.2, 4.4, and 4.6: https://sourceforge.net/projects/lazarus/files/Lazarus%20Linux%20amd64 %20DEB/ Considering that zeljko is currently actively working on getting GTK3 to a usable state of course you need to use the current development version and not a release. Quote from: marcov on March 01, 2026, 03:36:07 pmQuote from: robert rozee on March 01, 2026, 02:23:31 pmas i pointed out earlier: we have one dead widget set (GTK2/3/etc), one legally toxic widget set (Qt5/6/etc), and a few obscure dribs-and-drabs that according to some don't even compile. The problem with the Toxic designation is that is the hardline GNU interpretation of the GPL, that is not commonly shared.  Granted, I can't identify the old clause that was in the GPL2 iirc for delivered with OS libraries any more in the GPL3. A clause that defanged the toxic bit (as you would use the QT delivered with the OS and its package systems). But that might just because I only superficially looked, and not really deep into the matter any more. The main libraries that the Qt widgetset provides and the LCL needs (core, gui and widgets) are released as LGPL, so it's no problem to link against them dynamically. What is an issue for non Open Source software however is to link against them statically. For Lazarus applications one might solve this by compiling libqt6pas statically, at least one would only need to have the Qt core libraries provided from the system like with GTK. ---------------------------------------------------------------------- robert rozee · 2026-03-03 04:23 Quote from: robert rozee on March 01, 2026, 05:20:01 am[...] given the impending demise of GTK2 that others predict, the abandonment of development of GTK3 by the GTK developers before it was even completed, i think it is sensible to label GTK as a poor project to pin one's hopes on [...] i'm getting the feeling i have been misled over the GTK2/3 situation - having relied upon what others had said about GTK being correct. further digging reveals another 'version of reality': GTK2 is alive and well, there is no further development being carried out because it is considered by the GTK developers to be a completed and stable project that has been that way for a number of years. GTK3, in the last year, has reached the same stage as GTK2. ie, GTK3 is also considered a 'complete and stable project' by the GTK developers. GTK4 is still under development, and as such still has 'unresolved issues'.from the perspective of the Lazarus (LCL) developers: the LCL interface to GTK2 is, and has been for quite some time, 'of production quality'. it is in a state where it can be used in shipping software products. as such, the interface is shipped with the Lazarus packages on Sourceforge. the LCL interface to GTK3 currently has issues, and is not of production quality. as such, it is not available in any shipping version of the Lazarus packages on Sourceforge. but it is getting there! GTK4, from the perspective of someone wanting to ship a software product using Lazarus, is a non-starter. one day, maybe, but certainly not in the near future.from the perspective of the Debian developers: they want to kill GTK2; they do not want anyone using it. they are happy with GTK3, and do want people using it. GTK4 is something for the future, but not a usable thing today.is the summary correct? it looks like there have been many red-herrings in the fish supply! cheers, rob. ---------------------------------------------------------------------- JuhaManninen · 2026-03-03 06:20 Quote from: robert rozee on March 02, 2026, 11:34:39 amwell, that excludes me from further discussions then - i only run the Lazarus packages downloadable from Sourceforge. Why? You seem to be interested in LCK-GTK3 development and would be a perfect beta tester. Yes, LCK-GTK3 is in beta state now. Lazarus trunk is very easy to download and build. ---------------------------------------------------------------------- MarkMLl · 2026-03-03 08:04 Quote from: robert rozee on March 03, 2026, 05:23:14 amGTK2 is alive and well, there is no further development being carried out because it is considered by the GTK developers to be a completed and stable project that has been that way for a number of years. It's alive, well, and imminently being dropped by the major distreaux. In a few months time you will not be able to rely on your users obtaining it easily. You will also not be able to obtain it easily as a developer, particularly if you are reluctant to go to a project's own repository and possibly build from source. MarkMLl ---------------------------------------------------------------------- tetrastes · 2026-03-03 09:12 Quote from: robert rozee on March 03, 2026, 05:23:14 am GTK4 is something for the future, but not a usable thing today.is the summary correct? No, for sure GTK4 is a usable thing today. https://gtk.org/: GTK4 is stable, GTK3 is old stable. In modern distros (including Debian 13) Gnome is based on GTK4. ---------------------------------------------------------------------- dbannon · 2026-03-03 09:21 Quote from: robert rozee on March 03, 2026, 05:23:14 ami'm getting the feeling i have been misled over the GTK2/3 situation - having relied upon what others had said about GTK being correct. further digging reveals another 'version of reality': No, not really. Maybe you have not been listening to what people here have been telling you ? Most of what you say in this post is 'right-ish' but perhaps your interpretation of it is a bit dodgy. Gtk2 is being dropped because (eg) its hard to make work with Wayland, its hard to maintain (because its old code thats been endlessly hacked and so on. Its worth noting that gtk3 and gtk4 are, in some way, derivatives of gtk2. They are not completely new products. All big code bases evolve over time, sometimes with small incremental changes, sometimes big shifts and version numbering. Lazarus, because it shields us from that constantly moving gtk target, hides those changes. Debian is dropping gtk2 because they consider having three GTKs there is just too much and most active projects have moved to gtk3 (and a few even to gtk4) or Qt5/6. There is no conspiracy here Robert, its how the software world works. If it was not like that we'd be still setting up octal numbers with switches and pressing 'clock' after each one. Despite what Mark says, I'll bet that there will be a distribution or two still shipping a version of gtk2 for some years. Who knows, maybe one that is Wayland and SystemD free. And runs 32bit code..... Davo ---------------------------------------------------------------------- robert rozee · 2026-03-03 11:10 Quote from: JuhaManninen on March 03, 2026, 07:20:42 am[...] You seem to be interested in LCK-GTK3 development and would be a perfect beta tester. Yes, LCL-GTK3 is in beta state now. Lazarus trunk is very easy to download and build. a few times i've attempted to report bugs, and provided fixes, but received fairly negative and unhelpful responses; i have no interest in wasting any more of my time in that direction. i am far more interested in creating my own projects written using Lazarus/FPC, and for that - code i am generally giving away to others - those projects need to be buildable using release-level tools. ie, downloadable from Sourceforge; as yet there is NO GTK3-capable version available on Sourceforge. Quote from: MarkMLl on March 03, 2026, 09:04:43 am[GTK2]'s alive, well, and imminently being dropped by the major distreaux. and this, they (Debian at least) seem to be doing as a means of forcing their own ideology upon everyone else. forced ideologies are a really good way to persuade me to walk away from a project. the last release of GTK2.x (2.24.33, on 21st December 2020) is only 5 years old, which is extremely young when compared to, for instance, win32, that has been around for over a quarter of century and is still supported in the latest release of Windows. the last release of GTK3.x (3.24.51, on 30 September 2025) is less than 6 months old! yet some folks seem to be suggesting that GTK3 is already obsolete and/or end-of-life. i am glad to see that there is work going on getting the LCL working with GTK3, as this seems (to me at least) to be the most sensible direction for the Lazarus project to be moving in. Quote from: dbannon on March 03, 2026, 10:21:06 am[...] GTK2 is being dropped because (eg) its hard to make work with Wayland, its hard to maintain (because its old code that [has] been endlessly hacked and so on. [...] Debian is dropping GTK2 because they consider having three GTKs there is just too much and most active projects have moved to GTK3 (and a few even to GTK4) or Qt5/6. from what i have read, Wayland has issues that preclude it being viewed as 'production level' just yet. and i also wonder what the purpose of creating Wayland actually was; X11 seems to work fine, while ever increasing processing power and available RAM negates complaints of any 'inefficiencies' X11 suffers from. Wayland looks very much like a solution looking for a problem. i would also ask the question - what is wrong with GTK2? there has been suggestions that the tools no longer exist to compile it, but i find this extremely hard to believe. and the GTK developers have marked it as 'complete', to me that suggests that it is code that requires no more work on it, not that it is no longer usable. cheers, rob   :-) ---------------------------------------------------------------------- MarkMLl · 2026-03-03 11:36 Quote from: robert rozee on March 03, 2026, 12:10:52 pmand this, they (Debian at least) seem to be doing as a means of forcing their own ideology upon everyone else. forced ideologies are a really good way to persuade me to walk away from a project. the last release of GTK2.x (2.24.33, on 21st December 2020) is only 5 years old, which is extremely young when compared to, for instance, win32, that has been around for over a quarter of century and is still supported in the latest release of Windows. As I've said elsewhere, I refuse to be an apologist for anybody. GTK (and Gnome in general) has a poor reputation with regards to the stability of its published API, particularly when compared with the stability of the Windows API. As such, Debian removing a library which has had no substantial work done on it for at least five years, during which time Linux has moved on with systemd, Wayland, displays with rapidly increasing pixel density and colour resolution, and the pressure of making sure that applications are accessible to the disadvantaged, makes life far easier for its community of package maintainers. There might possibly have been an alternative course of saying "this should work but we don't recommend it": that would be viable if the only compatibility issues related to the application side of the widget set, but would not be viable if the GTK2 package maintainers found that it would no longer work with the current kernel (including device driver modules) etc. and could get no help from the GTK developers. So I don't think we can fairly criticise Debian for removing GTK2 on the grounds of no longer being maintainable, even if we can criticise them for blocking FPC on the grounds that it can (but doesn't have to) call GTK2 facilities. MarkMLl ---------------------------------------------------------------------- robert rozee · 2026-03-03 11:50 Quote from: MarkMLl on March 03, 2026, 12:36:40 pm[...] if the GTK2 package maintainers found that it would no longer work with the current kernel (including device driver modules) etc. and could get no help from the GTK developers [...] is it the case that GTK2 has compatibility issues with the current Linux kernel? or upcoming kernels? or with any of the existing X11/etc libraries? the only issue i've heard of involving GTK2 is that Wayland has issues with it - and that sounds like a problem within Wayland, not GTK2    btw: do we have any timeline for when GTK3 will be supported in a release of the Lazarus IDE on Sourceforge? probably a question for zeljko, but i don't want to put any pressure on him! cheers, rob   :-) ---------------------------------------------------------------------- Thausand · 2026-03-04 03:33 I not know if mention in thread (it is write about also FPC/Lazarus): https://www.theregister.com/2026/02/26/debian_14_will_drop_gtk2/ ---------------------------------------------------------------------- dbannon · 2026-03-04 08:11 Quote from: robert rozee on March 03, 2026, 12:50:51 pmbtw: do we have any timeline for when GTK3 will be supported in a release of the Lazarus IDE on Sourceforge? probably a question for zeljko, but i don't want to put any pressure on him! https://forum.lazarus.freepascal.org/index.php/topic,73583.msg577544.h tml#msg577544 But that will clearly depend on community support. Thats how open souce works. Davo ---------------------------------------------------------------------- zeljko · 2026-03-04 10:12 Quote from: robert rozee on March 03, 2026, 12:50:51 pmQuote from: MarkMLl on March 03, 2026, 12:36:40 pm[...] if the GTK2 package maintainers found that it would no longer work with the current kernel (including device driver modules) etc. and could get no help from the GTK developers [...] is it the case that GTK2 has compatibility issues with the current Linux kernel? or upcoming kernels? or with any of the existing X11/etc libraries? the only issue i've heard of involving GTK2 is that Wayland has issues with it - and that sounds like a problem within Wayland, not GTK2    btw: do we have any timeline for when GTK3 will be supported in a release of the Lazarus IDE on Sourceforge? probably a question for zeljko, but i don't want to put any pressure on him! cheers, rob   :-) My plan is that Lazarus 5.0 will be gtk3 based on linux (so gtk3  = default). When ? Don't ask me that ---------------------------------------------------------------------- PascalDragon · 2026-03-05 20:55 Quote from: robert rozee on March 03, 2026, 12:50:51 pmthe only issue i've heard of involving GTK2 is that Wayland has issues with it - and that sounds like a problem within Wayland, not GTK2    GTK2 doesn't have issues with Wayland, GTK2 doesn't support Wayland. It's a different display backend to X11 and thus needs completely new code to support it. So this is not a problem of Wayland, but a problem of GTK2 simply no longer being actively developed. ---------------------------------------------------------------------- robert rozee · 2026-03-05 22:56 Quote from: PascalDragon on March 05, 2026, 09:55:14 pmQuote from: robert rozee on March 03, 2026, 12:50:51 pmthe only issue i've heard of involving GTK2 is that Wayland has issues with it - and that sounds like a problem within Wayland, not GTK2    GTK2 doesn't have issues with Wayland, GTK2 doesn't support Wayland. It's a different display backend to X11 and thus needs completely new code to support it. So this is not a problem of Wayland, but a problem of GTK2 simply no longer being actively developed. i disagree with your view. GTK2 predated Wayland by many years, therefore it is up to Wayland to change, not GTK2. was Wayland not designed with some level of compatibility, so that it would operate with other existing software? you seem to be suggesting that every time a 'chunk' of Linux is replaced it is ok for that to break every other chunk that interfaces with it. that is insane!! cheers, rob   :-) ---------------------------------------------------------------------- Fred vS · 2026-03-05 23:12 Quote from: robert rozee on March 05, 2026, 11:56:56 pmGTK2 predated Wayland by many years, therefore it is up to Wayland to change, not GTK2. Wayland will not change, and to ensure compatibility with X11 (essential), they offer XWayland a X11 layer. XWayland can handle GTK2 (exclusively compatible with X11), including installing the GTK2 package. However, the problem (if I understand correctly) is that the latest Wayland distributions refuse to include GTK2 in their package list, even though they include XWayland, which is capable of handling it. How long Wayland distributions will continue to include XWayland is another story. ---------------------------------------------------------------------- dbannon · 2026-03-06 00:44 Quote from: Fred vS on March 06, 2026, 12:12:27 amHowever, the problem (if I understand correctly) is that the latest Wayland distributions refuse to include GTK2 in their package list, even though they include XWayland, which is capable of handling it. Yes, the distros want to drop gtk2 for space and maintenance reasons. So, firstly, drop it from default install, probably still be in repository. So, an app that lists t as a dependency will pull it down. But sooner or later, drop from repo. QuoteHow long Wayland distributions will continue to include XWayland is another story. In our particular case, both Qt5 and Qt6 work much better with XWayland (via xcb). ---------------------------------------------------------------------- robert rozee · 2026-03-06 03:28 presumably XWayland is a project that is 'tied in' with Wayland, hence XWayland can just be considered as the portion of Wayland that is responsible for communicating with GTK2 et al. being that XWayland and Wayland are just different parts of the same thing, it seems to say that Wayland is in designed to interface with GTK2 et al, albeit that the design is imperfect - i'm assuming that the reports we hear of things not working right relate to the GTK2<->XWayland<->Wayland connections. it sounds like PascalDragon saying "GTK2 doesn't support Wayland" is entirely false information; GTK2 is perfectly capable of talking to XWayland, which in turn is perfectly capable of talking to Wayland - apart from XWayland not doing a 100% perfect job. as for PascalDragon's claim that everything is "a problem of GTK2 simply no longer being actively developed" is, i am afraid to say, somewhat childish - and an insult against the GTK developers. the developers of GTK worked for years on GTK2 to bring it to a point of being a 'production ready' project. GTK2 is today a complete, working product, it has been this for around 5 years. Wayland/XWayland is a beta product that lacks the ability (at the moment) of slotting in as a substitute for X11. cheers, rob   :-( ---------------------------------------------------------------------- dbannon · 2026-03-06 06:30 Quote from: robert rozee on March 06, 2026, 04:28:25 ampresumably XWayland is a project that is 'tied in' with Wayland, hence XWayland can just be considered as the portion of Wayland that is responsible for communicating with GTK2 et al. More correct to say that XWayland implements an X11 server that can, in turn, talk to Wayland on behalf of its clients.  Quotebeing that XWayland and Wayland are just different parts of the same thing, .... - i'm assuming that the reports we hear of things not working right relate to the GTK2<->XWayland<->Wayland connections. XWayland is seen as a temporary measure while people shift to a (hopefully complete) Wayland. Its built from XOrg and maintained by the Wayland team. The people who pay the Wayland team (for the XWayland work) will almost certainly not be willing to do so indefinitely. If you would like to help with that task, or pay the people currently doing it, please get in touch with them, its certainly not our business here. Quoteit sounds like PascalDragon saying "GTK2 doesn't support Wayland" is entirely false No, its entirely true. Wayland sits there waiting for a client that talks Wayland-ese to contact it. It might be a gtk3, Qt5, Qt6 app OR, XWayland making out its a Wayland speaking app. Your argument is like me claiming to speak Chinese because I have a friend who does and he can translate for me. Quoteas for PascalDragon's claim that everything is "a problem of GTK2 simply no longer being actively developed" is, i am afraid to say, somewhat childish - and an insult against the GTK developers. the developers of GTK worked for years on GTK2 to bring it to a point of being a 'production ready' project. GTK2 is today a complete, working product, it has been this for around 5 years. Wayland/XWayland is a beta product that lacks the ability (at the moment) of slotting in as a substitute for X11. While I agree about both the readiness and the appropriateness of Wayland, its not something I, you and anyone else here can do anything about. Very big money drives the development of Linux these days, not eager volunteers. And the providers of that money want a more secure and more maintainable replacement for Xorg. Personally, I will regret the passing of XOrg but I am not going to rail against it, especially on a Forum that has absolutely no say in the decision. Gtk2 is no longer being developed because the developers drew a line across it and said that further development (including an interface to Wayland) will be called Gtk3. Then they did the same with Gtk3 and made Gtk4. However, gtk2 is open source, its quite possible to fork it and continue its development. Someone here mentioned a project that was so closely tied to Gtk2 that they have done just that. Lazarus could join it but it would be, IMHO  a very wasteful exercise. Gtk2 is past its use by date. Its flogging a dead horse. It has ceased to be. It is a dead widget set. Please stop this conspiracy theory agenda. No one is lying to you, what on earth would we have to gain if we were ? Davo EDIT : Should I lock this topic ?   I was hoping to use it to report on FPC/Lazarus's journey through Debian's process but it has wondered off track a bit. 11 pages ?? D ---------------------------------------------------------------------- MarkMLl · 2026-03-06 07:28 Quote from: dbannon on March 06, 2026, 07:30:20 amGtk2 is no longer being developed because the developers drew a line across it and said that further development (including an interface to Wayland) will be called Gtk3. Then they did the same with Gtk3 and made Gtk4. That is the important thing. And while a certain amount of "baying at the Moon" is OK in private, if this spills over into public criticism of Debian or of any of the foundation projects it will be to the detriment of this community: Pascal's credibility as an ongoing language is sufficiently tenuous that we can't afford that. Robert: with respect, I'm talking to you. I feel that apart from that this discussion has probably run its course and locking it would be justified. MarkMLl ---------------------------------------------------------------------- robert rozee · 2026-03-06 12:56 Quote from: dbannon on March 06, 2026, 07:30:20 am [...]  And the providers of that money want a more secure and more maintainable replacement for Xorg. Personally, I will regret the passing of XOrg but I am not going to rail against it, especially on a Forum that has absolutely no say in the decision. [...] Gtk2 is past its use by date. Its flogging a dead horse. It has ceased to be. It is a dead widget set. i have yet to hear any compelling argument as to why Xorg (X11) or GTK2 are no longer fit for purpose. i've certainly heard many nebulous claims such as 'it is insecure', 'it is old', 'no one uses it any more', but i have not heard any specific examples. all i've heard is what is essentially 'advertising hype', the sort of stuff that makes for good advertising content designed to capture customers. or youtube videos. or AI slop. can anyone provide examples where: Xorg (X11) has been the cause of a security failure due to defects in the Xorg code or design? GTK2 has been the cause of a security failure due to defects in the GTK2 code or design?for both Xorg (X11) and GTK2, i have heard complaints that keeping them is consuming disk space. but then today disk space is incredibly cheap compared to just 2 or 3 few years back - 32gb of flash memory costs less than $5, and the binary footprint of both projects together would fit into a minuscule corner of that 32gb. i'd estimate the actual hardware cost of keeping Xorg (X11) and GTK2 on an individual linux machine would be no more than a few cents. i've also heard complaints that Xorg (X11) and GTK2 are not as fast as the proposed replacements. but again, computrons are so incredibly cheap these days that speed of code execution is irrelevant in any but a tiny fraction of cases. the same holds for RAM usage - RAM is cheap as chips, and will continue to get cheaper once the AI boom has done its thing. and as for (non-security) bugs within the code: sure, GTK2 has some things that do not work correctly, but these things are well understood since the code has been (essentially) frozen for the past few years. those who write code that interfaces with GTK2 (i'm taking here about our solo UI programmer, zeljko) has done a sterling job in working around those things in GTK2 that are 'less-than-perfect'. it is a fact that all software has bugs; we document them and provide workarounds. i feel we need replacements for Xorg (X11) and GTK2 as much as we need a new design of fork to enable us to eat faster and more efficiently. or a better design of paperclip, or any number of 'new things' that are no better than the 'old things' we already have. Quote from: dbannon on March 06, 2026, 07:30:20 am [...] Please stop this conspiracy theory agenda. No one is lying to you, what on earth would we have to gain if we were? [...] some folks are picking up on the 'advertising hype' and re- broadcasting it as "fact". it is not a conspiracy, it is just people doing what people do - they hear a well dressed-up opinion, and innocently dress it up as 'fact'. it is the same sort of perfectly innocent gossip that used to get witches burnt at the stake. the one thing that irks me most, is when intelligent folks start accepting things as "fact" when there is no actual evidence to back it up. as i said above, i've seen no compelling arguments for replacing Xorg (X11) or for removing GTK2 from distros; what i have seen is hyperbole being accepted by folks who should know better. Quote from: dbannon on March 06, 2026, 07:30:20 am [...] Should I lock this topic? [...] i notice there are around 700 threads on this section of the forums (Lazarus » Forum » Programming » Operating Systems » Linux), and that this topic has received 43422 views. it is ranking at number 3 on the most viewed list, which to me seems pretty impressive. forum members are interested in the discussion, and while i agree that most everything that there is to say has already been said, i feel that 'locking' the topic would cast a shadow over the integrity of freepascal.org as an open community. cheers, rob. ---------------------------------------------------------------------- MarkMLl · 2026-03-06 14:10 Quote from: robert rozee on March 06, 2026, 01:56:56 pmi notice there are around 700 threads on this section of the forums (Lazarus » Forum » Programming » Operating Systems » Linux), and that this topic has received 43422 views. it is ranking at number 3 on the most viewed list, which to me seems pretty impressive. forum members are interested in the discussion, [...] No, forum members are interested to know what Debian's doing and the rest of the views are from bots. Whatever we think about it the migration to Wayland is a "done deal", and shooting ones mouth off in public about that will not be to the advantage of this community. Me, I've got Debian 13 on some systems but am not likely to go beyond that /because/ of the Wayland and GTK2 issue; if I live long enough I'll look at something like Arch. The discussion at El Reg https://forums.theregister.com/forum/all/2026 /02/26/debian_14_will_drop_gtk2/ has a very interesting recent posting from "drankinatty", I won't quote it in full for copyright reasons but QuoteThis is the correct way to look at the issue. Gtk+2 was the last Gtk before they went off chasing CSS themes, that in the end made a majority of the interface look like vanilla milk-toast. Gtk+2 is complete. I like that view. It was an excellent toolkit when it was finished, and the code hasn't changed. The issue for "complete" packages is simply one of "does it still build?", and if not, "is it a new compiler option default change?" or similar that just needs to be updated in the build files? (most are, few are actual API/ABI breaks) ... But the bottom line is still that we are in no real position to fight a Debian policy decision. MarkMLl ---------------------------------------------------------------------- marcov · 2026-03-06 14:13 Quote from: robert rozee on March 06, 2026, 01:56:56 pmQuote from: dbannon on March 06, 2026, 07:30:20 am [...]  And the providers of that money want a more secure and more maintainable replacement for Xorg. Personally, I will regret the passing of XOrg but I am not going to rail against it, especially on a Forum that has absolutely no say in the decision. [...] Gtk2 is past its use by date. Its flogging a dead horse. It has ceased to be. It is a dead widget set. i have yet to hear any compelling argument as to why Xorg (X11) or GTK2 are no longer fit for purpose. How about sitting through several lectures at Fosdem in the Xorg/X11 trajectory and hear its developers describe the protocol as a train wreck loaded with legacy technical debt. That includes two keynotes by Keith Packard. Back then Wayland/Weston was still in its early stages, but back then Mir was really considered as the most likely next display server architecture. ---------------------------------------------------------------------- robert rozee · 2026-03-06 14:17 Quote from: Fred vS on March 06, 2026, 02:44:20 pm"Wayland is the future," they say. Okay, but the present says, "Wayland belongs in the trash." circling back to GTK2 et al, does Wayland tend to favour Qt over GTK? or to put it another way, could the rise of Wayland be seen as a means of advancing the fortunes of Qt and its associated contributor license agreement? Quote from: MarkMLl on March 06, 2026, 03:10:59 pm[...] the rest of the views are from bots [...] that is quite a bizarre claim indeed. i feel that much of the discussion in this thread has been well formed, certainly not produced by (automated?) "bots"! you are sounding a little paranoid. Quote from: MarkMLl on March 06, 2026, 03:10:59 pm[...] Whatever we think about it the migration to Wayland is a "done deal", and shooting ones mouth off in public about that will not be to the advantage of this community [...] no, it is not a "done deal". Wayland could easily come undone if en- mass developers refused to support it. distros would need to quickly back down if major package contributors refused to comply - imagine if Libre Office and The GIMP said no. btw, i see that two postings by Fred vS have just disappeared from this thread - what happened to them? cheers, rob. ---------------------------------------------------------------------- marcov · 2026-03-06 14:32 Quote from: robert rozee on March 06, 2026, 03:17:49 pmQuote from: Fred vS on March 06, 2026, 02:44:20 pm"Wayland is the future," they say. Okay, but the present says, "Wayland belongs in the trash." circling back to GTK2 et al, does Wayland tend to favour Qt over GTK? or to put it another way, could the rise of Wayland be seen as a means of advancing the fortunes of Qt and its associated contributor license agreement? No, I'd advise you to drink less conspiracy juice. It is just the same reason as why FPC doesn't port FPC 2.4.0 to new architectures. Time. ---------------------------------------------------------------------- Fred vS · 2026-03-06 14:48 Quote from: robert rozee on March 06, 2026, 03:17:49 pmbtw, i see that two postings by Fred vS have just disappeared from this thread - what happened to them? I destroyed them. They were excessive, therefore insignificant. ---------------------------------------------------------------------- MarkMLl · 2026-03-06 14:54 Quote from: robert rozee on March 06, 2026, 03:17:49 pmQuote from: MarkMLl on March 06, 2026, 03:10:59 pm[...] the rest of the views are from bots [...]that is quite a bizarre claim indeed. i feel that much of the discussion in this thread has been well formed, certainly not produced by (automated?) "bots"! you are sounding a little paranoid. Are you /really/ incapable of distinguishing between "views are from bots" and "produced by ... bots" ? My apologies to the community if that sounds ad-hominem, but I'm beginning to find this quite exasperating and feel that the discussion could be usefully truncated at the point where we worked out what Debian was actually doing. MarkMLl ---------------------------------------------------------------------- robert rozee · 2026-03-06 15:16 Quote from: MarkMLl on March 06, 2026, 03:54:29 pm[...] Are you /really/ incapable of distinguishing between "views are from bots" and "produced by ... bots" ? [...] "the christmas cards i receive are from my grandmother"; i would consider it peculiar to think or say "the christmas cards i receive are produced by my grandmother". unless my grandmother was a mechanical printing press, which i can assure you she was not. i suspect it is a cultural difference that caused the confusion, i am English, and speak English. i assume you are American, and speak American? perhaps you could have said "... the rest of the views have clearly been generated by bots (as i disagree with them) and repeated here by misguided organic humans ...". cheers, rob   :-) ---------------------------------------------------------------------- MarkMLl · 2026-03-06 15:32 Quote from: robert rozee on March 06, 2026, 04:16:17 pmi assume you are American, and speak American? I suggest you avoid Sussex after having said that. I'm British: Welsh. MarkMLl ---------------------------------------------------------------------- robert rozee · 2026-03-06 15:42 Mae hynny'n egluro popeth, ta  Iechyd da, rob   :-) ---------------------------------------------------------------------- Martin_fr · 2026-03-06 16:35 Quote from: robert rozee on March 06, 2026, 04:16:17 pmQuote from: MarkMLl on March 06, 2026, 03:54:29 pm[...] Are you /really/ incapable of distinguishing between "views are from bots" and "produced by ... bots" ? [...] "the christmas cards i receive are from my grandmother"; i would consider it peculiar to think or say "the christmas cards i receive are produced by my grandmother". unless my grandmother was a mechanical printing press, which i can assure you she was not. i suspect it is a cultural difference that caused the confusion, i am English, and speak English. i assume you are American, and speak American? perhaps you could have said "... the rest of the views have clearly been generated by bots (as i disagree with them) and repeated here by misguided organic humans ...". Well, forgive me (both of you) for chiming in here... But here is the original post: Quote from: MarkMLl on March 06, 2026, 03:10:59 pmQuote from: robert rozee on March 06, 2026, 01:56:56 pmi notice there are around 700 threads on this section of the forums (Lazarus » Forum » Programming » Operating Systems » Linux), and that this topic has received 43422 views. it is ranking at number 3 on the most viewed list, which to me seems pretty impressive. forum members are interested in the discussion, [...] No, forum members are interested to know what Debian's doing and the rest of the views are from bots. His (MarkMLI's) use of "views" is a clear reference to the quoted statement that the topic is being viewed (i.e. view = read). So clearly not "view" as "expressed opinion" that someone would have written (produced). ---------------------------------------------------------------------- robert rozee · 2026-03-06 17:11 Quote from: Martin_fr on March 06, 2026, 05:35:24 pm[...] [MarkMLI's] use of "views" is a clear reference to the quoted statement that the topic is being viewed (i.e. view = read). So clearly not "view" as "expressed opinion" that someone would have written (produced). Martin, you raise an excellent point! to be completely unambiguous perhaps Mark should have written "... and the rest of the viewings are from bots", but i think that by that point Mark and I had both got caught up in the heat of the moment. in retrospect, i must concede that we were both (inadvertently) talking about completely different things.  ain't English a wonderfully confusing language... cheers, rob   :-) ---------------------------------------------------------------------- Martin_fr · 2026-03-06 17:41 Quote from: robert rozee on March 06, 2026, 06:11:55 pmain't English a wonderfully confusing language...Off topic, but nothing ain't not as totally ambivalent as the wordly productions made by one Sir Humphrey Appleby ... But it is thanks to him that the point risen by you that is the starting point to my excursion into the world of possibilities with reference to interpretations has had its prove received. ---------------------------------------------------------------------- MarkMLl · 2026-03-06 20:48 Quote from: Martin_fr on March 06, 2026, 06:41:38 pmQuote from: robert rozee on March 06, 2026, 06:11:55 pmain't English a wonderfully confusing language...Off topic, but nothing ain't not as totally ambivalent as the wordly productions made by one Sir Humphrey Appleby ... But it is thanks to him that the point risen by you that is the starting point to my excursion into the world of possibilities with reference to interpretations has had its prove received. Indeed, not to mention the diversions provided by his colleague Mr Bernard Woolley. However what is- at least marginally- relevant is that most programming languages (with the notable exception of the long-forgotten Dragon BASIC) are based on the English vocabulary, some approximation of English syntax, and- in particular- the American English character set. That latter becomes relevant when trying to extend Pascal/ALGOL with arbitrary user-declared operators. X11's support of Unicode is adequate for that sort of thing, including when it's tunneled over SSH. The fact that Wayland is likely- particularly if XWayland withers- to be inadequate is obviously highly regrettable, /but/ there's a limit to how vociferous a community such as ours can be without its rebounding on us. /Perhaps/ if we'd picked up on the tunneled-operation issues earlier and "made waves" in the context of Wayland, we might have got somewhere. But making an argument that something like GTK2, effectively "put out to pasture" by its own developers, should be kept alive indefinitely is far more difficult. QuoteBut what to do with the packages that still need Gtk+2?. Considering Gtk+2 "complete" is the correct approach. Distros need not support it, but they shouldn't discourage community support for it either. Take Arch as a study. Gtk+2 was just recently removed from Arch proper, but it is still community maintained in AUR and available to anyone running arch that needs or wants it. You just have to download the AUR package, gzip -d, and then "makepkg -s" and you have your Gtk+2. This model has worked well, and to Arch's credit they have developed the AUR and provide a good community support for those wishing (or needing) to have access to "complete" packages. Arch doesn't provide it as part of the distro, it doesn't meet the active- upstream criteria, but it is still available for those that need it. After all, "choice" was the corner-stone of the open-source movement and for Linux in particular. A "forced choice" is no choice at all, it's an ultimatum. Above from drankinatty's contribution at https://forums.theregister.co m/forum/all/2026/02/26/debian_14_will_drop_gtk2/ . I agree wholeheartedly with his points, but the one that I'm trying to make here is that upsetting the Debian (hence Ubuntu etc.) community would probably rebound on us. MarkMLl ---------------------------------------------------------------------- Fred vS · 2026-03-06 22:05 Quote from: MarkMLl on March 06, 2026, 09:48:38 pm... but the one that I'm trying to make here is that upsetting the Debian (hence Ubuntu etc.) community would probably rebound on us. Who cares? Free Pascal is "Free" as in "Freedom" and has no fear of its community's opinions, even if it bothers the most powerful. ---------------------------------------------------------------------- Fred vS · 2026-03-06 22:27 Linux represents only a very small percentage of PC users. Debian should therefore do everything in its power to protect FPC, a compiler of such high quality. Shame on them. ---------------------------------------------------------------------- Fred vS · 2026-03-06 22:51 And I understand Rob's indignation. Removing GTK2 by default while integrating XWayland is yet another tactic to genocide step by step X11, with arguments like "it's too old," "it no longer has commits," and "it takes up space." [EDIT] About the argument "GTK2 package takes up place": - Download Size: ~2.5 MB to 3.5 MB (compressed). - Installed Size: ~12 MB to 15 MB of disk space. Okay, I'll stop. ---------------------------------------------------------------------- robert rozee · 2026-03-07 02:25 Quote from: MarkMLl on March 06, 2026, 09:48:38 pm[...] Above from drankinatty's contribution at https://forums.theregister.com/forum/all /2026/02/26/debian_14_will_drop_gtk2/ . I agree wholeheartedly with his points, but the one that I'm trying to make here is that upsetting the Debian (hence Ubuntu etc.) community would probably rebound on us. i find it hard to believe that the Debian folks are so thin-skinned that they would be offended by this little thread of ours. then again, perhaps our thread is just one of a thousand others popping up on the internet that collectively pose some sort of a perceived 'threat' to Debian's world view. words, freely spoken, can be powerful things. and i was pleased to read The Register thread, which largely encapsulates many of my own sentiments. i had not previously been aware of that thread, which amongst other things explains what i consider to be one of the practical problems between Lazarus and Qt: Quote from: MarkMLl posting on TheRegisterQt [...] needs a special shim library since FPC has the feature [...] that it can't interwork directly with code that uses C++ classes etc.https://forums.theregiste r.com/forum/all/2026/02/26/debian_14_will_drop_gtk2/#c_5236355 i was not aware of this C++ issue. Mark - are you able to expand more on this outside of the thread? i would very much like to be able to statically bind libQt5Pas into a lazarus-created ELF binary, if it were possible. btw: i started another thread titled "could Ardour's YTK be used as a GTK2 replacement?" (https://forum.lazarus.freepascal.org/index.php/topic,73590.0.html), but only MarcoV posted to it - and that was not a very useful posting. while i'm not in a position to kick off such a project (integrating YTK into Lazarus as another widget set option) myself, it does seem like something worth exploring. no, not writing code! exploring in the sense of gaining some idea of how much bulk it would add to an ELF binary, to what degree YTK retains function calls that the LCL would need - and what needed function calls are missing, and the extent of modification to the LCL that would be needed. being able to (via existing GTK2 support along with incorporating YTK source) would add another string to Lazarus' bow going forward. cheers, rob   :-) ---------------------------------------------------------------------- Fred vS · 2026-03-07 02:40 Quote from: robert rozee on March 07, 2026, 03:25:58 am btw: i started another thread titled "could Ardour's YTK be used as a GTK2 replacement?" (https://forum.lazarus.freepascal.org/index.php/topic,73590.0.html), but only MarcoV posted to it - and that was not a very useful posting. while i'm not in a position to kick off such a project (integrating YTK into Lazarus as another widget set option) myself, it does seem like something worth exploring. no, not writing code! exploring in the sense of gaining some idea of how much bulk it would add to an ELF binary, to what degree YTK retains function calls that the LCL would need - and what needed function calls are missing, and the extent of modification to the LCL that would be needed. being able to (via existing GTK2 support along with incorporating YTK source) would add another string to Lazarus' bow going forward. Hi Rob. But using YTK will pose the same problem as with GTK2. Wayland distributions (for sure) will not install it by default. ---------------------------------------------------------------------- robert rozee · 2026-03-07 02:50 Quote from: Fred vS on March 07, 2026, 03:40:09 am[...] But using YTK will pose the same problem as with GTK2. Wayland distributions (for sure) will not install it by default. as far as i have been able to determine, YTK is not a standalone library, it is a set of routines that are bound into your application. essentially the Ardour developers have taken the GTK2 source, stripped out a whole load of stuff that was unnecessary, then taken the rest and turned it into a set routines that you statically link into your project. a google summary suggests: "Static Linking: In most official Ardour bundles, YTK is linked directly into the application, meaning you don't need to manage it as a separate, space-consuming "package" on your system." (as with any such offerings, it should be taken with a pinch of salt. none-the-less it hints at what may be true/possible) so the result should be an ELF binary that is perhaps 5mb larger (at a guess), but that talks directly to the X11 layer. within that ELF binary there will be the existing GTK2 portions of the LCL, plus an 'interface layer' of routines that have been cherry-picked from the GTK2 widget set sources. yes, it is double-handling data, but no more so that the current approach of working through GTK2's .so libraries. cheers, rob   :-) ---------------------------------------------------------------------- valdir.marcos · 2026-03-07 02:58 Quote from: robert rozee on March 07, 2026, 03:25:58 amQuote from: MarkMLl on March 06, 2026, 09:48:38 pm[...] Above from drankinatty's contribution at https://forums.theregister.com/forum/all/2026/02/26/de bian_14_will_drop_gtk2/ . I agree wholeheartedly with his points, but the one that I'm trying to make here is that upsetting the Debian (hence Ubuntu etc.) community would probably rebound on us. i find it hard to believe that the Debian folks are so thin-skinned that they would be offended by this little thread of ours. then again, perhaps our thread is just one of a thousand others popping up on the internet that collectively pose some sort of a perceived 'threat' to Debian's world view. words, freely spoken, can be powerful things. and i was pleased to read The Register thread, which largely encapsulates many of my own sentiments. i had not previously been aware of that thread, which amongst other things explains what i consider to be one of the practical problems between Lazarus and Qt: Quote from: MarkMLl posting on TheRegisterQt [...] needs a special shim library since FPC has the feature [...] that it can't interwork directly with code that uses C++ classes etc.https://forums.theregiste r.com/forum/all/2026/02/26/debian_14_will_drop_gtk2/#c_5236355 i was not aware of this C++ issue. Mark - are you able to expand more on this outside of the thread? i would very much like to be able to statically bind libQt5Pas into a lazarus-created ELF binary, if it were possible. btw: i started another thread titled "could Ardour's YTK be used as a GTK2 replacement?" (https://forum.lazarus.freepascal.org/index.php/topic,73590.0.html), but only MarcoV posted to it - and that was not a very useful posting. while i'm not in a position to kick off such a project (integrating YTK into Lazarus as another widget set option) myself, it does seem like something worth exploring. no, not writing code! exploring in the sense of gaining some idea of how much bulk it would add to an ELF binary, to what degree YTK retains function calls that the LCL would need - and what needed function calls are missing, and the extent of modification to the LCL that would be needed. being able to (via existing GTK2 support along with incorporating YTK source) would add another string to Lazarus' bow going forward. cheers, rob   :-)I am also interested in Mark's knowledge and point of view. ---------------------------------------------------------------------- Fred vS · 2026-03-07 03:08 Quote from: robert rozee on March 07, 2026, 03:50:01 amas far as i have been able to determine, YTK is not a standalone library, it is a set of routines that are bound into your application. essentially the Ardour developers have taken the GTK2 source, stripped out a whole load of stuff that was unnecessary, then taken the rest and turned it into a set routines that you statically link into your project. Well "stripped out a whole load of stuff that was unnecessary," worries me a bit (not some methods used by LCL I hope) and how to adapt those routines for Lazarus (mountain of work). ---------------------------------------------------------------------- robert rozee · 2026-03-07 03:19 Quote from: Fred vS on March 07, 2026, 04:08:17 am[...] Well "stripped out a whole load of stuff that was unnecessary," worries me a bit (not some methods used by LCL I hope) and how to adapt those routines for Lazarus (mountain of work). well that is the $65,536 question - has anything vital (for the LCL) been removed? as for adapting to Lazarus, i'm rather hopeful that what remains is complete enough to build into a library that can be statically linked to a Lazarus program - that would be the 'easy' approach. i have seen chatter online suggesting that YTK could be adopted by projects other than Ardour as a means of avoiding the need to adapt to GTK3/4/etc or Qt5/6/etc. the down side, of course, is that you are then getting tied into X11 remaining available, but i can't see XWayland being cast adrift in the immediate future. cheers, rob   :-) ---------------------------------------------------------------------- Fred vS · 2026-03-07 03:29 Quote from: robert rozee on March 07, 2026, 04:19:55 amQuote from: Fred vS on March 07, 2026, 04:08:17 am[...] Well "stripped out a whole load of stuff that was unnecessary," worries me a bit (not some methods used by LCL I hope) and how to adapt those routines for Lazarus (mountain of work). well that is the $65,536 question - has anything vital (for the LCL) been removed? as for adapting to Lazarus, i'm rather hopeful that what remains is complete enough to build into a library that can be statically linked to a Lazarus program - that would be the 'easy' approach. i have seen chatter online suggesting that YTK could be adopted by projects other than Ardour as a means of avoiding the need to adapt to GTK3/4/etc or Qt5/6/etc. the down side, of course, is that you are then getting tied into X11 remaining available, but i can't see XWayland being cast adrift in the immediate future. cheers, rob   :-) Well, I saw that @valdir.marcos had joined the fight, so I'm not worried anymore, you'll manage. ---------------------------------------------------------------------- valdir.marcos · 2026-03-07 04:26 Quote from: Fred vS on March 07, 2026, 04:29:39 amQuote from: robert rozee on March 07, 2026, 04:19:55 amQuote from: Fred vS on March 07, 2026, 04:08:17 am[...] Well "stripped out a whole load of stuff that was unnecessary," worries me a bit (not some methods used by LCL I hope) and how to adapt those routines for Lazarus (mountain of work). well that is the $65,536 question - has anything vital (for the LCL) been removed? as for adapting to Lazarus, i'm rather hopeful that what remains is complete enough to build into a library that can be statically linked to a Lazarus program - that would be the 'easy' approach. i have seen chatter online suggesting that YTK could be adopted by projects other than Ardour as a means of avoiding the need to adapt to GTK3/4/etc or Qt5/6/etc. the down side, of course, is that you are then getting tied into X11 remaining available, but i can't see XWayland being cast adrift in the immediate future. cheers, rob   :-) Well, I saw that @valdir.marcos had joined the fight, so I'm not worried anymore, you'll manage.  Qt6 is not a silver bullet. With X11 and Gtk2 being also retired on Debian, I am trying as many alternatives as possible. ---------------------------------------------------------------------- Fred vS · 2026-03-07 06:14 Quote from: valdir.marcos on March 07, 2026, 05:26:06 amWith X11 and Gtk2 being also retired on Debian, I am trying as many alternatives as possible. Hum, ok for X11 out of Debian distros but XWayland will not being retired and will remain a critical part of Debian for the foreseeable future. So YTK (as static) could be used for a long time. (Idem for fpGUI and MSEgui by the way). ---------------------------------------------------------------------- dbannon · 2026-03-07 07:19 But why on earth bother ?  If you really must target gtk2 (and assuming xwayland remains with us) just build an Appimage, the build tools will gather all the necessary (and only the necessary) libraries and bundle then all up in the app image. Quite easy right now ! I'd give it a try if I could find a distribution that has, already, removed its gtk2. Not sure when Forky is gtk2 free but our apps, dependent on it are due to be 'cleaned' on 13 March. XWayland has no deadline mentioned on the debian tracking site. Davo ---------------------------------------------------------------------- robert rozee · 2026-03-07 07:24 Quote from: dbannon on March 07, 2026, 08:19:07 amBut why on earth bother? to add another string to our bow. cheers, rob   :-) ---------------------------------------------------------------------- cdbc · 2026-03-07 07:42 Hi Davo I think you should take a look at 'ElementaryOS' it's up to version 8.1.1 and it's very modern... Regards Benny ---------------------------------------------------------------------- MarkMLl · 2026-03-07 09:40 Quote from: robert rozee on March 07, 2026, 03:25:58 ami find it hard to believe that the Debian folks are so thin-skinned that they would be offended by this little thread of ours. then again, perhaps our thread is just one of a thousand others popping up on the internet that collectively pose some sort of a perceived 'threat' to Debian's world view. words, freely spoken, can be powerful things. They won't be, for the simple reason that like the rest of the industry they no longer give a damn about Pascal which from their POV is obsolete and had a number of fundamental design flaws. Let's face it, the only people reading this forum are those with something invested in the language, although there is a risk that bots feeding LLMs could get the wrong end of the stick and contribute to the spread of misinformation. However, any attempt to take the war to Debian and to post in their workflow that they're wrong and that the Pascal community /demands/ that they do such-and-such would be ill-advised, since at the very least it would be seized upon by the http://doc.cat- v.org/bell_labs/why_pascal/why_pascal_is_not_my_favorite_language.pdf crowd and would risk discouraging potential users. Quoteand i was pleased to read The Register thread, which largely encapsulates many of my own sentiments. i had not previously been aware of that thread, which amongst other things explains what i consider to be one of the practical problems between Lazarus and Qt: I had advance warning of it, and knew that there were one or two things that Liam (the author) was uncertain about (specifically, whether it applied to FPC or Lazarus). By the time it had been OKed by their editors the situation had been clarified in this forum, and I hope that my comments got the message out to the wider community. Note that while I was critical of Debian's procedures, I tried to structure my criticism as a general point rather than being a demand from FPC and/or Lazarus: -----8<----- Debian appears to have no concept of the fact that a development tool can have Separate Compilation (with strong type checking etc.), and assumes that if a package includes a precompiled interface unit then any libraries used by that interface unit are hard prerequisites for the entire package. That's wrong, that needs to be fixed, and that's Debian's problem. ----->8----- That thread didn't attract any "Pascal sucks!" comments, so I feel that I succeeded. Quotei was not aware of this C++ issue. Mark - are you able to expand more on this outside of the thread? i would very much like to be able to statically bind libQt5Pas into a lazarus-created ELF binary, if it were possible. I'd much rather not spend more time on this right now, but the bottom line is that while FPC code can interwork with either C or C++ (non- OO) code the object models are distinct. That's why whenever linking to an API which is only expressed in C++ (with OO) there's likely to be half-arsed suggestions like "tell the other project that they ought to maintain a pure-C version of their API"... which is of course fairly close to the ongoing GTK2 issue. For anything else I suggest looking back through this thread for mention of libQt#Pas since I'm pretty sure that there's discussion of the extent to which static linkage would fall foul of the Qt licensing terms. MarkMLl ---------------------------------------------------------------------- robert rozee · 2026-03-07 12:21 Quote from: MarkMLl on March 07, 2026, 10:40:26 am[...] there is a risk that bots feeding LLMs could get the wrong end of the stick and contribute to the spread of misinformation [...] any information presented on the internet will be picked up and turned into AI slop by LLMs. the only way to prevent this from happening is to remain absolutely silent on everything, and that would just be silly - the internet would fall silent, dare i say it even cease to be. Quote from: MarkMLl on March 07, 2026, 10:40:26 amQuotei was not aware of this C++ issue. Mark - are you able to expand more on this outside of the thread? i would very much like to be able to statically bind libQt5Pas into a lazarus-created ELF binary, if it were possible.[... look] back through this thread for mention of libQt#Pas since I'm pretty sure that there's discussion of the extent to which static linkage would fall foul of the Qt licensing terms. to date no one has presented, not have i have found, any legal opinions that a 'shim' such as LibQtxPas provides any sort of legal protection against the Qt licensing terms, nor any legal opinions that preclude linking dynamically against Qt directly. i believe that said legal opinions are a fantasy invention, and challenge anyone who claims otherwise to  front up with said legal opinions. to object to including Qt symbol names in an ELF binary file's dynamic symbol table (ie, linking dynamically against Qt directly, not via a shim), one would need to argue that the Qt folks held some copyright or registered trade mark over the symbol names themselves. such an argument would not hold up in any court of law - it would be tantamount to allowing the copyrighting of names such as Peter, Paul, Mark, and John, or numbers such as 379076547650851467. cheers, rob   :-) ---------------------------------------------------------------------- zeljko · 2026-03-07 13:52 Quote from: dbannon on March 07, 2026, 08:19:07 amBut why on earth bother ?  If you really must target gtk2 (and assuming xwayland remains with us) just build an Appimage, the build tools will gather all the necessary (and only the necessary) libraries and bundle then all up in the app image. Quite easy right now ! I'd give it a try if I could find a distribution that has, already, removed its gtk2. Not sure when Forky is gtk2 free but our apps, dependent on it are due to be 'cleaned' on 13 March. XWayland has no deadline mentioned on the debian tracking site. Davo Hey, I've implemented gtk3 missing puzzles for you, can you test trunk laz ? ---------------------------------------------------------------------- ginoo · 2026-03-07 14:57 I'd also like to try the IDE with GTK3 so I can let you know if I encounter any problems. I'm using Lazarus 4.6, should I use that or something else? If the tests have to be done with the trunk ones, I won't try it; I'll have to work on it. ---------------------------------------------------------------------- zeljko · 2026-03-07 15:05 Quote from: ginoo on March 07, 2026, 03:57:59 pmI'd also like to try the IDE with GTK3 so I can let you know if I encounter any problems. I'm using Lazarus 4.6, should I use that or something else? If the tests have to be done with the trunk ones, I won't try it; I'll have to work on it. No, for gtk3 you must use trunk lazarus. Manually git checkout and then build, or use fpcupdeluxe. ---------------------------------------------------------------------- valdir.marcos · 2026-03-07 15:38 Quote from: zeljko on March 04, 2026, 11:12:34 amQuote from: robert rozee on March 03, 2026, 12:50:51 pmQuote from: MarkMLl on March 03, 2026, 12:36:40 pm[...] if the GTK2 package maintainers found that it would no longer work with the current kernel (including device driver modules) etc. and could get no help from the GTK developers [...] is it the case that GTK2 has compatibility issues with the current Linux kernel? or upcoming kernels? or with any of the existing X11/etc libraries? the only issue i've heard of involving GTK2 is that Wayland has issues with it - and that sounds like a problem within Wayland, not GTK2    btw: do we have any timeline for when GTK3 will be supported in a release of the Lazarus IDE on Sourceforge? probably a question for zeljko, but i don't want to put any pressure on him! cheers, rob   :-)My plan is that Lazarus 5.0 will be gtk3 based on linux (so gtk3  = default). When ? Don't ask me that Excellent information! Fingers crossed! Thanks. ---------------------------------------------------------------------- JuhaManninen · 2026-03-07 18:07 Quote from: ginoo on March 07, 2026, 03:57:59 pmIf the tests have to be done with the trunk ones, I won't try it; I'll have to work on it. C'mon, it is very easy to download and test. Something like this: $ git clone https://gitlab.com/freepascal.org/lazarus/lazarus.git $ cd lazarus $ make $ ./lazarus --pcp=~/.lazarus_trunk & The last pcp parameter ensures your trunk experiment uses a separate config dir (~/.lazarus_trunk) and does not interfere with the release version config. Then build Lazarus for GTK3 from the Tools menu (Configure Build Lazarus). ---------------------------------------------------------------------- Fred vS · 2026-03-07 19:07 Quote from: JuhaManninen on March 07, 2026, 07:07:49 pmQuote from: ginoo on March 07, 2026, 03:57:59 pmIf the tests have to be done with the trunk ones, I won't try it; I'll have to work on it. C'mon, it is very easy to download and test. Something like this: $ git clone https://gitlab.com/freepascal.org/lazarus/lazarus.git $ cd lazarus $ make $ ./lazarus --pcp=~/.lazarus_trunk & The last pcp parameter ensures your trunk experiment uses a separate config dir (~/.lazarus_trunk) and does not interfere with the release version config. Then build Lazarus for GTK3 from the Tools menu (Configure Build Lazarus). Yep, nice commands and WOW @zeljko well done, Lazarus-GTK3 is working great. ---------------------------------------------------------------------- PascalDragon · 2026-03-07 23:07 Quote from: robert rozee on March 05, 2026, 11:56:56 pmQuote from: PascalDragon on March 05, 2026, 09:55:14 pmQuote from: robert rozee on March 03, 2026, 12:50:51 pmthe only issue i've heard of involving GTK2 is that Wayland has issues with it - and that sounds like a problem within Wayland, not GTK2    GTK2 doesn't have issues with Wayland, GTK2 doesn't support Wayland. It's a different display backend to X11 and thus needs completely new code to support it. So this is not a problem of Wayland, but a problem of GTK2 simply no longer being actively developed. i disagree with your view. GTK2 predated Wayland by many years, therefore it is up to Wayland to change, not GTK2. Wayland by itself does not care about GUI frameworks. Just like X11 by itself does not care about them. Both are just display protocols. And by design the Wayland display protocol is different from the X11 protocol. That's the whole point of it, because this way the developers hope to address the flaws of the X11 protocol. Quote from: robert rozee on March 05, 2026, 11:56:56 pmwas Wayland not designed with some level of compatibility, so that it would operate with other existing software? you seem to be suggesting that every time a 'chunk' of Linux is replaced it is ok for that to break every other chunk that interfaces with it. that is insane!! Correct, the Wayland protocol itself was designed without compatibility. Quote from: robert rozee on March 06, 2026, 04:28:25 ampresumably XWayland is a project that is 'tied in' with Wayland, hence XWayland can just be considered as the portion of Wayland that is responsible for communicating with GTK2 et al. being that XWayland and Wayland are just different parts of the same thing, it seems to say that Wayland is in designed to interface with GTK2 et al, albeit that the design is imperfect - i'm assuming that the reports we hear of things not working right relate to the GTK2<->XWayland<->Wayland connections. it sounds like PascalDragon saying "GTK2 doesn't support Wayland" is entirely false information; GTK2 is perfectly capable of talking to XWayland, which in turn is perfectly capable of talking to Wayland - apart from XWayland not doing a 100% perfect job. No, Wayland and XWayland are not the same thing. XWayland is an X11 server implemented on top of Wayland together with some special side channels to allow functionality of X11 that Wayland itself does not support (like allowing applications to position windows which Wayland itself does not allow). Wayland, XWayland and X11 are developed by the same group of people (FreeDesktop.org), however they are nevertheless distinct projects. And XWayland is an optional component that can be uninstalled which in turn means that X11 applications (and thus GTK2 applications) will not work on a Wayland based system. Quote from: robert rozee on March 06, 2026, 04:28:25 amas for PascalDragon's claim that everything is "a problem of GTK2 simply no longer being actively developed" is, i am afraid to say, somewhat childish - and an insult against the GTK developers. the developers of GTK worked for years on GTK2 to bring it to a point of being a 'production ready' project. GTK2 is today a complete, working product, it has been this for around 5 years. Wayland/XWayland is a beta product that lacks the ability (at the moment) of slotting in as a substitute for X11. No, it's not an insult to the GTK2 developers, it's simply how development of such frameworks is: The developers have simply moved on from GTK2 to GTK3 just like they had moved on from GTK1 and now they're moving on to GTK4. Same with Qt where the developers of Qt moved on from Qt3 to Qt4 to Qt5 and now Qt6. Same also with for example SDL where development is now happening in SDL3 while SDL1 is no longer developed and SDL2 is in maintenance mode. It's same with FPC: no one is putting any work anymore in the 1.99 compiler or the 2.4.0 compiler. Quote from: robert rozee on March 07, 2026, 03:25:58 amand i was pleased to read The Register thread, which largely encapsulates many of my own sentiments. i had not previously been aware of that thread, which amongst other things explains what i consider to be one of the practical problems between Lazarus and Qt: Quote from: MarkMLl posting on TheRegisterQt [...] needs a special shim library since FPC has the feature [...] that it can't interwork directly with code that uses C++ classes etc.https://forums.theregiste r.com/forum/all/2026/02/26/debian_14_will_drop_gtk2/#c_5236355 i was not aware of this C++ issue. Mark - are you able to expand more on this outside of the thread? i would very much like to be able to statically bind libQt5Pas into a lazarus-created ELF binary, if it were possible. FPC does not support the name mangling and the vtables that C++ classes require for correct functionality (*), thus a wrapper library (like Qt*Pas) is required that takes in the C++ API and provides it in turn as a C API that FPC can work with. (*) To be more precise FPC supports some C++ mangling as well as primitive C++ classes in the form of the cppdecl calling convention and cppclass, however these are not usable enough for directly declaring a C++ class like the Qt ones. Quote from: robert rozee on March 07, 2026, 01:21:12 pmto date no one has presented, not have i have found, any legal opinions that a 'shim' such as LibQtxPas provides any sort of legal protection against the Qt licensing terms, nor any legal opinions that preclude linking dynamically against Qt directly. i believe that said legal opinions are a fantasy invention, and challenge anyone who claims otherwise to  front up with said legal opinions. to object to including Qt symbol names in an ELF binary file's dynamic symbol table (ie, linking dynamically against Qt directly, not via a shim), one would need to argue that the Qt folks held some copyright or registered trade mark over the symbol names themselves. such an argument would not hold up in any court of law - it would be tantamount to allowing the copyrighting of names such as Peter, Paul, Mark, and John, or numbers such as 379076547650851467. The Qt core libraries that Lazarus requires (namely QtCore, QtGui and QtWidgets) are licensed as LGPL (this page shows which modules are licensed as GPL instead). The whole point of the LGPL compared to GPL is to allow dynamic linking, meaning the library code in question resides in a dynamic library (DLL on Windows, SO on Linux, DynLib on macOS) instead of statically inside the program module. The Qt*Pas modules are licensed with the same license as FPC's RTL and FCL or Lazarus' LCL, namely LGPL-with-static-linking-exception, meaning that you can statically link in that library even in a proprietary application. So as long as you use Qt itself using dynamic libraries it does not matter whether you use the Qt*Pas library dynamically or statically linked. ---------------------------------------------------------------------- robert rozee · 2026-03-07 23:49 Quote from: PascalDragon on March 08, 2026, 12:07:08 am[...] So as long as you use Qt itself using dynamic libraries it does not matter whether you use the Qt*Pas library dynamically or statically linked. thank you PascalDragon, this is useful information! next question - how do i statically link the "Qt*Pas" library to my application? this is something i have never done before, and i have absolutely no idea how it is done. cheers, rob   :-) ---------------------------------------------------------------------- valdir.marcos · 2026-03-08 00:04 Quote from: PascalDragon on March 08, 2026, 12:07:08 amQuote from: robert rozee on March 05, 2026, 11:56:56 pmQuote from: PascalDragon on March 05, 2026, 09:55:14 pmQuote from: robert rozee on March 03, 2026, 12:50:51 pmthe only issue i've heard of involving GTK2 is that Wayland has issues with it - and that sounds like a problem within Wayland, not GTK2    GTK2 doesn't have issues with Wayland, GTK2 doesn't support Wayland. It's a different display backend to X11 and thus needs completely new code to support it. So this is not a problem of Wayland, but a problem of GTK2 simply no longer being actively developed. i disagree with your view. GTK2 predated Wayland by many years, therefore it is up to Wayland to change, not GTK2. Wayland by itself does not care about GUI frameworks. Just like X11 by itself does not care about them. Both are just display protocols. And by design the Wayland display protocol is different from the X11 protocol. That's the whole point of it, because this way the developers hope to address the flaws of the X11 protocol. Quote from: robert rozee on March 05, 2026, 11:56:56 pmwas Wayland not designed with some level of compatibility, so that it would operate with other existing software? you seem to be suggesting that every time a 'chunk' of Linux is replaced it is ok for that to break every other chunk that interfaces with it. that is insane!! Correct, the Wayland protocol itself was designed without compatibility. Quote from: robert rozee on March 06, 2026, 04:28:25 ampresumably XWayland is a project that is 'tied in' with Wayland, hence XWayland can just be considered as the portion of Wayland that is responsible for communicating with GTK2 et al. being that XWayland and Wayland are just different parts of the same thing, it seems to say that Wayland is in designed to interface with GTK2 et al, albeit that the design is imperfect - i'm assuming that the reports we hear of things not working right relate to the GTK2<->XWayland<->Wayland connections. it sounds like PascalDragon saying "GTK2 doesn't support Wayland" is entirely false information; GTK2 is perfectly capable of talking to XWayland, which in turn is perfectly capable of talking to Wayland - apart from XWayland not doing a 100% perfect job. No, Wayland and XWayland are not the same thing. XWayland is an X11 server implemented on top of Wayland together with some special side channels to allow functionality of X11 that Wayland itself does not support (like allowing applications to position windows which Wayland itself does not allow). Wayland, XWayland and X11 are developed by the same group of people (FreeDesktop.org), however they are nevertheless distinct projects. And XWayland is an optional component that can be uninstalled which in turn means that X11 applications (and thus GTK2 applications) will not work on a Wayland based system. Quote from: robert rozee on March 06, 2026, 04:28:25 amas for PascalDragon's claim that everything is "a problem of GTK2 simply no longer being actively developed" is, i am afraid to say, somewhat childish - and an insult against the GTK developers. the developers of GTK worked for years on GTK2 to bring it to a point of being a 'production ready' project. GTK2 is today a complete, working product, it has been this for around 5 years. Wayland/XWayland is a beta product that lacks the ability (at the moment) of slotting in as a substitute for X11. No, it's not an insult to the GTK2 developers, it's simply how development of such frameworks is: The developers have simply moved on from GTK2 to GTK3 just like they had moved on from GTK1 and now they're moving on to GTK4. Same with Qt where the developers of Qt moved on from Qt3 to Qt4 to Qt5 and now Qt6. Same also with for example SDL where development is now happening in SDL3 while SDL1 is no longer developed and SDL2 is in maintenance mode. It's same with FPC: no one is putting any work anymore in the 1.99 compiler or the 2.4.0 compiler. Quote from: robert rozee on March 07, 2026, 03:25:58 amand i was pleased to read The Register thread, which largely encapsulates many of my own sentiments. i had not previously been aware of that thread, which amongst other things explains what i consider to be one of the practical problems between Lazarus and Qt: Quote from: MarkMLl posting on TheRegisterQt [...] needs a special shim library since FPC has the feature [...] that it can't interwork directly with code that uses C++ classes etc.https://forums.theregiste r.com/forum/all/2026/02/26/debian_14_will_drop_gtk2/#c_5236355 i was not aware of this C++ issue. Mark - are you able to expand more on this outside of the thread? i would very much like to be able to statically bind libQt5Pas into a lazarus-created ELF binary, if it were possible. FPC does not support the name mangling and the vtables that C++ classes require for correct functionality (*), thus a wrapper library (like Qt*Pas) is required that takes in the C++ API and provides it in turn as a C API that FPC can work with. (*) To be more precise FPC supports some C++ mangling as well as primitive C++ classes in the form of the cppdecl calling convention and cppclass, however these are not usable enough for directly declaring a C++ class like the Qt ones. Quote from: robert rozee on March 07, 2026, 01:21:12 pmto date no one has presented, not have i have found, any legal opinions that a 'shim' such as LibQtxPas provides any sort of legal protection against the Qt licensing terms, nor any legal opinions that preclude linking dynamically against Qt directly. i believe that said legal opinions are a fantasy invention, and challenge anyone who claims otherwise to  front up with said legal opinions. to object to including Qt symbol names in an ELF binary file's dynamic symbol table (ie, linking dynamically against Qt directly, not via a shim), one would need to argue that the Qt folks held some copyright or registered trade mark over the symbol names themselves. such an argument would not hold up in any court of law - it would be tantamount to allowing the copyrighting of names such as Peter, Paul, Mark, and John, or numbers such as 379076547650851467. The Qt core libraries that Lazarus requires (namely QtCore, QtGui and QtWidgets) are licensed as LGPL (this page shows which modules are licensed as GPL instead). The whole point of the LGPL compared to GPL is to allow dynamic linking, meaning the library code in question resides in a dynamic library (DLL on Windows, SO on Linux, DynLib on macOS) instead of statically inside the program module. The Qt*Pas modules are licensed with the same license as FPC's RTL and FCL or Lazarus' LCL, namely LGPL-with-static-linking-exception, meaning that you can statically link in that library even in a proprietary application. So as long as you use Qt itself using dynamic libraries it does not matter whether you use the Qt*Pas library dynamically or statically linked. Very important information. Thanks. ---------------------------------------------------------------------- Fred vS · 2026-03-08 00:17 Quote from: PascalDragon on March 08, 2026, 12:07:08 amQuote from: robert rozee on March 06, 2026, 04:28:25 amas for PascalDragon's claim that everything is "a problem of GTK2 simply no longer being actively developed" is, i am afraid to say, somewhat childish - and an insult against the GTK developers. the developers of GTK worked for years on GTK2 to bring it to a point of being a 'production ready' project. GTK2 is today a complete, working product, it has been this for around 5 years. Wayland/XWayland is a beta product that lacks the ability (at the moment) of slotting in as a substitute for X11. No, it's not an insult to the GTK2 developers, it's simply how development of such frameworks is: The developers have simply moved on from GTK2 to GTK3 just like they had moved on from GTK1 and now they're moving on to GTK4. Same with Qt where the developers of Qt moved on from Qt3 to Qt4 to Qt5 and now Qt6. Same also with for example SDL where development is now happening in SDL3 while SDL1 is no longer developed and SDL2 is in maintenance mode. It's same with FPC: no one is putting any work anymore in the 1.99 compiler or the 2.4.0 compiler. Okay, this isn't meant as an insult to the GTK2 developers, but in my opinion, removing a set of widgets still used by many applications (especially many Lazarus apps, but also many others), some of which are real gems that are no longer updated because they're perfect, seems unfair. But hey, it's their choice. And thank you Sven for your always clear explanations. ---------------------------------------------------------------------- MarkMLl · 2026-03-08 07:45 Quote from: PascalDragon on March 08, 2026, 12:07:08 amWayland by itself does not care about GUI frameworks. Just like X11 by itself does not care about them. Both are just display protocols. And by design the Wayland display protocol is different from the X11 protocol. That's the whole point of it, because this way the developers hope to address the flaws of the X11 protocol. There's an old saying (old, at least, by the standards of the industry) along the lines of X11 being the worst display protocol possible apart from everything else. MarkMLl ---------------------------------------------------------------------- Schmitty2005 · 2026-03-08 15:03 Quote from: zeljko on March 07, 2026, 04:05:40 pmQuote from: ginoo on March 07, 2026, 03:57:59 pmI'd also like to try the IDE with GTK3 so I can let you know if I encounter any problems. I'm using Lazarus 4.6, should I use that or something else? If the tests have to be done with the trunk ones, I won't try it; I'll have to work on it. No, for gtk3 you must use trunk lazarus. Manually git checkout and then build, or use fpcupdeluxe. Where should problems with GTK3 be reported ?  The forums ? or Bug Tracker ? Or both as needed ? Ubuntu 24.04 LTS.  Using Wayland.  EDIT : Error also occurs with X11.xorg EDIT : Compiled with FPC 3.2.3 (Fixes branch) from FPCupDeluxe EDIT: Also, as seen in the pic,  none of the Menu bar items are visible on the main menu bar. I will delete my configs and try againNew configs make no difference, but I recompiled from using stable to trunk using FPCUPDELUXE and got this : ---------------------------------------------------------------------- JuhaManninen · 2026-03-08 15:47 Quote from: Schmitty2005 on March 08, 2026, 04:03:15 pmI will delete my configs and try again, but I recompiled from using stable to trunk using FPCUPDELUXE and got this : It says IDE 4.6. something went wrong. You can create bug reports in bug tracker, but make them specific and include example code. If you are not sure if you found a bug or a feature, ask the forum first. ---------------------------------------------------------------------- Schmitty2005 · 2026-03-08 16:14 Quote from: JuhaManninen on March 08, 2026, 04:47:40 pmQuote from: Schmitty2005 on March 08, 2026, 04:03:15 pmI will delete my configs and try again, but I recompiled from using stable to trunk using FPCUPDELUXE and got this : It says IDE 4.6. something went wrong. You can create bug reports in bug tracker, but make them specific and include example code. If you are not sure if you found a bug or a feature, ask the forum first. There was no project or example code, this is simply rebuilding Lazarus with GTK3 instead of default QT5 or GTK2.  It is a lot better than it was several months ago, but still not usable.  This was also built with FPC 3.2.3.  Should I be using  FPC 3.2.2 instead ? ---------------------------------------------------------------------- dsiders · 2026-03-08 17:28 Quote from: JuhaManninen on March 08, 2026, 04:47:40 pmQuote from: Schmitty2005 on March 08, 2026, 04:03:15 pmI will delete my configs and try again, but I recompiled from using stable to trunk using FPCUPDELUXE and got this : It says IDE 4.6. something went wrong. You can create bug reports in bug tracker, but make them specific and include example code. If you are not sure if you found a bug or a feature, ask the forum first. I'm quoting Juha, but it's intended for the original poster... 4.6 doesn't include the bulk of the GTK3 patches that have occurred lately. They're in trunk (4.99). ---------------------------------------------------------------------- Schmitty2005 · 2026-03-08 18:56 Quote from: dsiders on March 08, 2026, 06:28:34 pmQuote from: JuhaManninen on March 08, 2026, 04:47:40 pmQuote from: Schmitty2005 on March 08, 2026, 04:03:15 pmI will delete my configs and try again, but I recompiled from using stable to trunk using FPCUPDELUXE and got this : It says IDE 4.6. something went wrong. You can create bug reports in bug tracker, but make them specific and include example code. If you are not sure if you found a bug or a feature, ask the forum first. I'm quoting Juha, but it's intended for the original poster... 4.6 doesn't include the bulk of the GTK3 patches that have occurred lately. They're in trunk (4.99). I had a bit of an FPCUpDeluxe snafu that built 4.6, but I had trunk selected.  Thank you for the clarification.   I am going to assume that this should be built with 3.2.2, because 3.2.4 is unreleased at this point, and there is no known release date that I have seen. Yes, trunk GTK3 seems functional with  minor issues. ---------------------------------------------------------------------- PascalDragon · 2026-03-09 20:57 Quote from: Fred vS on March 08, 2026, 01:17:08 amOkay, this isn't meant as an insult to the GTK2 developers, but in my opinion, removing a set of widgets still used by many applications (especially many Lazarus apps, but also many others), some of which are real gems that are no longer updated because they're perfect, seems unfair. It's not the GTK developers who decide this, it's the distribution maintainers. Though to be fair the GTK developers would probably prefer for GTK2 to be long gone already and GTK3 being on the way out, considering that their preference is on GTK4 now... 🤔 ---------------------------------------------------------------------- Fred vS · 2026-03-09 22:17 Quote from: PascalDragon on March 09, 2026, 09:57:07 pmIt's not the GTK developers who decide this, it's the distribution maintainers. T Of course I'm aware of that. But these distros are often influenced by Big Data (GTK among others). Quote from: PascalDragon on March 09, 2026, 09:57:07 pmThough to be fair the GTK developers would probably prefer for GTK2 to be long gone already and GTK3 being on the way out, considering that their preference is on GTK4 now... 🤔 Yes, but I don't think they'd be offended to know that applications that run on their old engine can still be useful and working. We completely understand that Wayland wants to wipe the slate clean, and I find that a little sad. And I'm willing to bet they won't remove GTK3, even though GTK4 is the default. (Because GTK3 is Wayland compatible.) That said, everyone does what they want, and it's great if you're happy with Wayland or distos without GTK2! ---------------------------------------------------------------------- Thaddy · 2026-03-11 09:43 Quote from: PascalDragon on March 09, 2026, 09:57:07 pmIt's not the GTK developers who decide this, it's the distribution maintainers. T Huh? It was the GTK developers who declared GTK2 unmaintained.... (Many moons ago, btw) So the distribution maintainers simply followed what the developers stated. That is quite a different truth from yours. ---------------------------------------------------------------------- robert rozee · 2026-03-11 10:54 Quote from: Thaddy on March 11, 2026, 10:43:02 amQuote from: PascalDragon on March 09, 2026, 09:57:07 pmIt's not the GTK developers who decide this, it's the distribution maintainers. T Huh? It was the GTK developers who declared GTK2 unmaintained [...] So the distribution maintainers simply followed what the developers stated. [...] it seems that you (and many others) are arguing that any piece of software that is considered by its developers to be feature complete, fully functional, and requiring of no further changes is immediately, by definition, 'unmaintained' and should be replaced/removed from distros?! from what folks seem to be saying, and my own observations of the whole ecosystem, the above is how Desktop Linux works, leaving everything in a continuous state of flux. as one package is replaced with a newer version this in turn triggers a need to replace any upstream or downstream packages; every single package needs to have a team of developers permanently 'attached' to it, perpetually ready to kick off a cycle of renewal when triggered by the renewal of any adjacent package. what has happened to the concept of stability in the world of Desktop Linux? the notion of things that work, have worked for years gone by, and will continue to work for many years into the future. just like microsoft's win32 API since 1998. cheers, rob   :-) ---------------------------------------------------------------------- marcov · 2026-03-11 10:58 Quote from: robert rozee on March 11, 2026, 11:54:26 amwhat has happened to the concept of stability in the world of Desktop Linux?  It never existed. moderator notice: Anyway, the reasons for deprecation of GTK2 is now off topic, since this is now going in circles and nothing changed for a couple of dozen posts. If you want to discuss it ad nauseam, use some Debian forum, where it belongs. ---------------------------------------------------------------------- MarkMLl · 2026-03-12 07:39 Quote from: marcov on March 11, 2026, 11:58:36 amQuote from: robert rozee on March 11, 2026, 11:54:26 amwhat has happened to the concept of stability in the world of Desktop Linux?  It never existed. I agree. While there's some binary compatibility across Linux versions and variants for small binary programs, as soon as you're talking about anything larger and /particularly/ when you're talking about GUI-based programs all compatibility goes out of the window. I can assure you that those of us who were around in the early '90s would have /loved/ something like AppImage, even though the duplication of libraries etc. has major storage implications. As it is, we just had to get used to building stuff from scratch if it wasn't available (and regularly updated) as a binary from the distro maintainer. That became a major pain for large applications like browsers when they became significant. QuoteIf you want to discuss it ad nauseam, use some Debian forum, where it belongs. Without dragging the FPC or wider Pascal communities into it please. MarkMLl ---------------------------------------------------------------------- dbannon · 2026-03-12 07:44 Quote from: marcov on March 11, 2026, 11:58:36 ammoderator notice: Anyway, the reasons for deprecation of GTK2 is now off topic, since this is now going in circles and nothing changed for a couple of dozen posts. If you want to discuss it ad nauseam, use some Debian forum, where it belongs. OK, thanks Marcov, I'll close this thread. For anyone who wants to continue it elsewhere - https://lists.debian.org/debian-devel/2026/01/msg00090.html contains a good starting point. https://archlinux.org/todo/gtk-2-eol/ - please don't just beat up Debian, all the other major distros heading the same way. https://artixlinux.org/ - as above https://www.theregister.com/2026/02/26/debian_14_will_drop_gtk2/ - a great place to tilt at windmills ! Thanks everyone for your positive contributions. Davo