[badsectoracula]

This wont be part of a Lazarus release any time soon (ok, it might be in 4.0 but i don't know when 4.0 will happen) as it is only on trunk, but recently i was fixing bugs for the Gtk1 backend. The neat bit is that Gtk1 is very small and while it isn't preinstalled anywhere nowadays (except Slackware) you can carry the .so as they are around 5-6MB or so. However it also supports static linking and after some quick hacking i made Lazarus to statically link against Gtk1 but dynamically link against X11, etc, thus making binaries that can run in pretty much every distro (assuming of course what Gtk1 provides is enough). The neat bit is that the static binary is only around 1.5MB larger than the equivalent binary linked dynamically with Gtk2.

Here is a little mesh viewer test for some docview-like API i wrote recently (not part of Lazarus itself, this is part of a package i use with common code across my Lazarus apps) that was statically compiled with Gtk1 on Slackware running on a Debian which has no Gtk1 libraries at all[0]. Also a bonus screenshot[1] with another mesh viewer (this is a different project[2]) compiled twice, once with the Gtk1 backend and once with the Qt6 backend with the exact same code (just changed the target "widgetset" from the project settings).

[0] https://i.imgur.com/Y4jvQMk.png

[1] https://i.imgur.com/NE2LB3U.png

[2] http://runtimeterror.com/tech/jtf/

[keyle]

God I only took a peek at the screenshots and I want that environment so bad. I miss it. I realise what it makes me sound like, sitting on my M2 32GB 1TB monster. Nostalgia hits you in the feels.

[abeyer]

I'd say it's a lot more than _just_ nostalgia, though that certainly can play in too... But there are plenty of aspects of this, like snappy interaction latencies and a small pool of simple but consistent UI components that behave the same every time you see them, that I think are objectively better than much of what we see today. There was absolutely something lost in consistency and quality when we resigned ourselves to most UIs starting with a blank HTML DOM and building their own custom UI from scratch.

[nxobject]

It's a 'brew install lazarus' away! It does a decent job at using Cocoa-like widgets as well, although it misses some of the animations you expect.

[versteegen]

Does FPC avoid using versioned symbols from glibc that would prevent it from running on distros without a recent glibc, unlike any C/C++ program compiled using system libc headers?

This is a particular problem with recent Slackware-current: I used to compile portable x86/64 linux binaries (from C+C++ sources or from FreeBASIC compiled to C) by patching out those versioned symbols using ld --wrap= flags, but since glibc 2.34 even that no longer works: https://news.ycombinator.com/item?id=32479545

[badsectoracula]

I think there was some effort to allow specifying versioned symbols or something along these lines that was inspired by some breakage introduced by a recent glibc, but i don't know where that went.

However the safe and really recommended approach is to link against older libraries (easiest way is to use a VM running an older Linux distro), like with C and C++. Free Pascal is largely self-contained so Free Pascal on an older distro is trivial and even if you have to build from source it is just a couple of commands.

[xyproto]

I like the idea if including the UI library. I know that ie. Ardour are not looking forward to upgrading from Gtk2.

Could this technique be used with Gtk4+Wayland as well?

[badsectoracula]

Well, Gtk4 isn't supported (in fact even Gtk3 support is buggy, AFAIK the original maintainer abandoned it after getting tired of Gtk4 breaking the API again - i think there is someone else fixing bugs for Gtk3 right now though but there isn't any Gtk4 code), though from a quick search it can be statically linked if you build it from source yourself (the Gtk developers do not seem to like that though and all comments i saw in a couple of relevant bugtracker posts were along the lines of "do not do that, we don't want to support that"). So assuming a Gtk4 backend is made and you are able to create a static Gtk4 library (together with static versions of all the libraries it needs aside from common stuff like the C library, OpenGL, etc) it should work.

It might be possible to link against Qt6 though (the LCL widgetset of which is more actively developed) but you'd still need to make a static library for both Qt6 and libQt6Pas (a "proxy" library that exposes a C API for Qt6 that LCL can use, currently it is part of the Lazarus project but there was some discussion recently to make it its own separate thing). Personally i've only tried linking statically against libQt6Pas (with the Qt6 libraries being linked dynamically so the program can use the distro libs) so i wont have to carry the libQt6Pas.so[0] (Qt6 is or at least should be available pretty much everywhere nowadays and will be around for years to come).

In general you should be able to link against any static C or C++ library (note that for the latter you also need to link against the C++ libraries).

[0] https://i.imgur.com/Cw89XtC.png

[parlortricks]

Would this GTK1 version work with Windows as well?

[badsectoracula]

I'm using this[0] version of Gtk which (AFAIK) is the latest stable Gtk 1.2 with Slackware's patches (gdk_pixbuf isn't the latest version, but i patched it to compile).

I do not see any Win32-specific code in there though, so it wouldn't compile. It might be interesting to try and make a Win32 backend (Gtk 1.2 was ported to Win32 but i think the port lived out of the main tree), especially a Win9x compatible one for retrocoding :-P. Though for Lazarus use it'd also need modifications on LCL/Gtk1 as in many places it uses X11 directly (and when it comes to retrocoding FPC and Lazarus do not support Win9x anymore, only Win2K and later).

[0] http://runtimeterror.com/pages/badsector/gtk12/