( I'm upstream of Castle Game Engine. I already posted about a related castle-model-viewer bugreport on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967795 . )
In Castle Game Engine, GTK 2 is used in 2 ways: 1. As a backend of our TCastleWindow. This was solved on our (upstream) side -- we introduced now a new backend CASTLE_WINDOW_GTK_3 and it's now default on Linux and FreeBSD. So all applications using TCastleWindow can be compiled to use GTK 2 instead of 3. More information on https://castle-engine.io/wp/2026/02/09/upgrade-to-gtk-3/ . So this should be solved once we (upstream) release new engine version (we plan to do it this month, February 2026) and Debian updates to it. 2. Another usage is through using LCL, this affects our editor (castle-editor) application. The editor doesn't use TCastleWindow, it uses Lazarus LCL + TCastleControl component. There are a few solutions to this usage: 2.1. In short, for Debian packaging, as a simplest solution we recommend to use LCL Qt5 widgetset for castle-editor. We did some fixes around TCastleControl + Qt5 widgetset in the past, and it should work nicely. Note that this is *not* what we will do as an upstream, in our releases on https://castle-engine.io/download . Using Qt5 widgetset would be risky for us, as it has to rely on libqt5pas, which changes API from time to time, and distributing a binary castle-editor that links to incompatible libqtpas would just crash on users. This will change once we use Snap / Flatpak for Linux releases (then we can package engine + proper libqtpas) but for current releases it would be bad. Anyhow, this problem doesn't concern Debian, where you can just make sure that libqt5pas and castle-editor are compatible, since you ship them both. 2.2. We could rely on Lazarus GTK 3 widgetset. It is unfortunately still not stable enough for us. Even testing with latest Lazarus "main", where "gtk3" is no longer marked "alpha". I mentioned details on https://castle-engine.io/wp/2026/02/09/upgrade-to-gtk-3/ . I want to work on this, and once done -> this can be a solution for both upstream and Debian packaging. But it may not be immediate. 2.3. There is also, but this is a more distant future, possibility to have castle-editor version that doesn't use LCL, and only uses TCastleWindow. So then our engine editor is also a "more typical" application using our engine. I actually started to play with this idea in the past, it's called castle-editor-portable, https://github.com/castle-engine/castle-engine/tree/master/tools/castle-editor-portable . But this needs a lot of work to be really "production" usage at this point. Regards, Michalis
