[Pkg-pascal-devel] Bug#967284: Bug#967284: castle-game-engine: depends on deprecated GTK 2

[Michalis Kamburelis]

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&section=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 <peter at pblackman.plus.com> 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
>