We use GTK2 in 2 ways in Castle Game Engine (CGE), and we have 2 plans how to get rid of it.
I wrote probably too many details below :) So, the short answer first: - We may be able to get rid of GTK2 dependency in CGE. - It requires doing 2 things by me in CGE. I will get back to you ~next week when this is done. - The necessary changes should be part of CGE 7.0-alpha.3 release, which I hope to do within ~2 weeks, so rather soon. - This will make both CGE and view3dscene free from GTK2 dependency. Details, and 2 ways how we use GTK2 in CGE right now: 1. The Castle Game Engine editor ( https://castle-engine.io/editor , in sources: tools/castle-editor ) is an application using Lazarus LCL. On Linux and FreeBSD it is mostly tested with LCL GTK2 widgetset, though in theory it could work with any LCL widgetset that works on these platforms (and has standard LCL components, including TOpenGLControl, with reliable and sufficiently complete implementation). So it is possible to get rid of GTK2 dependency by just recompiling the editor with different LCL widgetset, like Qt5 or GTK3. - GTK3 widgetset? No. It is sadly not production-ready in LCL. So say docs on wiki and talk on Lazarus mailing list. Quick test with CGE editor using GTK3 widgetset confirms it's very buggy: broken image colors, broken layout, disappearing controls after Alt+Tab (on 1st form, ChooseProject), then broken button icons, half-visible bottom tabs (on ProjectForm), and then access violation when creating OpenGL context (when opening the project). - Qt5 widgetset? Almost yes. Testing today showed it's mostly ready. I only found 1 (Qt5-widgetset-specific) bug, which I hope to deal with soon: Sometimes when selecting a file with preview (e.g. glTF file) there's weird blinking of the bottom UI, as if some control was hidden/shown each frame. That's my TODO to workaround it. Note that it is critical that you use only Lazarus >= 2.2.4, with my merge request applied to Qt5 widgetset: https://gitlab.com/freepascal.org/lazarus/lazarus/-/merge_requests/95/ . I made explicit check for this at the beginnig of https://github.com/castle-engine/castle-engine/blob/master/tools/castle-editor/code/frameviewfile.pas , so compilation will even fail with clear error with older LCL. This should not be a problem for Debian -- bookworm has Lazarus 2.2.6 I see, bullseye-backports has 2.2.4 also OK (ref: https://packages.debian.org/search?keywords=lazarus&searchon=names&suite=all§ion=all ). This also means adding dependency on libqt5pas to the Debian CGE package that includes the editor. (I am not sure which Debian package it is at this point.) I am not yet sure what to do for upstream downloads ( https://castle-engine.io/download ). Linking them to old GTK2 widgetset (as we do now) sucks, but linking to libqt5pas would also be problematic: most users don't have it installed, and would observe editor just crash at run. Anyhow, that's my (upstream) issue to decide, Debian packaging has it simpler since you can just depend on libqt5pas. 2. Our TCastleWindow class has a number of "backends" like GTK2. Our "backends" are quite similar to the concept of "widgetsets" in LCL, but much simpler since our TCastleWindow is much simpler beast than LCL. The TCastleWindow class is used by most of our examples and is recommended to use if you want to "just make a game engine" similar to other game engines. Our "New Project" templates set up the project to use TCastleWindow. The view3dscene also uses TCastleWindow. There are a few TCastleWindow backends ( https://castle-engine.io/castlewindow_backends ). There's even one backend using LCL under the hood ( CASTLE_WINDOW_LCL ) and thus using in theory any LCL widgetset. But we don't advise using CASTLE_WINDOW_LCL (or LCL), that's why we have created TCastleWindow in the end: TCastleWindow is more portable (e.g. works on Android and iOS and Nintendo Switch without any additional effort, so one can recompile desktop (Linux, Windows, macOS) applications easily). It also has a more efficient loop processing (so e.g. "mouse look" works smoothly with TCastleWindow). And in general TCastleWindow (without CASTLE_WINDOW_LCL) means we have 1 less dependency in CGE, so things are simpler. In general we "win" because TCastleWindow is just a simple thing (just a class with OpenGL context). Applications using TCastleWindow *do not* depend on LCL, unless they specifically use CASTLE_WINDOW_LCL backend. By default on Linux and FreeBSD we use GTK2 backend, CASTLE_WINDOW_GTK_2 . That said, we can and want to develop a GTK3 backend for TCastleWindow. Should be straightforward adjustment to our GTK2 backend. Note: FPC/Lazarus folks could make it easier by providing GTK3 bindings in FPC, just like GTK2, but it seems there's no consensus if/how to do this ( https://gitlab.com/freepascal.org/fpc/source/-/issues/39989 ). So I guess in CGE upstream we'll have to fork these units: https://gitlab.com/freepascal.org/lazarus/lazarus/-/tree/main/lcl/interfaces/gtk3 . I suppose Debian will also want to provide Pascal GTK3 bindings (in a way independent from Lazarus or LCL), so CGE on Debian should use Debian's version of Pascal GTK3 bindings. We risk having some work to synchronize all these GTK3 bindings versions, but I don't think we can avoid it, until FPC or Lazarus decide on where to centralize Pascal GTK3 bindings. I see that Abou (Debian developer, also on Pkg-pascal-devel list) is also participating in https://gitlab.com/freepascal.org/fpc/source/-/issues/39989 so I guess he's tracking that. Regards, Michalis śr., 27 wrz 2023 o 12:27 Peter B <[email protected]> napisał(a): > > On 27/09/2023 10:45, Bastian Germann wrote: > > On Sun, 9 Aug 2020 23:01:12 +0200 Michalis Kamburelis wrote: > >> Upgrade to GTK3 is planned. > > > > Would it be possible to build with qt5 instead? From a Debian packaging > > perspective, > > this should already work as opposed to gtk3. > > > > Hi Bastian, > > That would maybe have possible if castle-game-engine was built with Lazarus, > but it is built with Gtk2 via fp-units-gtk2. > > Michalis is the expert here, but FWIW, my guess is no. > > > Regards, > Peter >
