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 
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.
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!!
Correct, the Wayland protocol itself was designed without compatibility.
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.
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.
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.
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.
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:
Qt [...] 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.theregister.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.
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.
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.
Recent
