Debian Bug report logs - #967284
castle-game-engine: depends on deprecated GTK 2

Reply or subscribe to this bug.

Display info messages

Message #5 received at maintonly@bugs.debian.org (full text, mbox, reply):

From: smcv@debian.org

To: maintonly@bugs.debian.org

Subject: castle-game-engine: depends on deprecated GTK 2

Date: Tue, 04 Aug 2020 11:34:15 +0100

Source: castle-game-engine
Severity: normal
User: pkg-gnome-maintainers@lists.alioth.debian.org
Usertags: gtk2 oldlibs
Control: block 947713 by -1

This package has Build-Depends on GTK 2 (libgtk2.0-dev), or produces
binary packages with a Depends on GTK 2.

GTK 2 was superseded by GTK 3 in 2011 (see
<https://bugs.debian.org/947713>). It no longer receives any significant
upstream maintenance, and in particular does not get feature development
for new features like UI scaling on high-pixel-density displays (HiDPI)
and native Wayland support. GTK 3 is in maintenance mode and GTK 4 is
approaching release, so it seems like a good time to be thinking about
minimizing the amount of GTK 2 in the archive.

GTK 2 is used by some important productivity applications like GIMP, and
has also historically been a popular UI toolkit for proprietary software
that we can't change, so perhaps removing GTK 2 from Debian will never be
feasible. However, it has reached the point where a dependency on it is
a bug - not a release-critical bug, and not a bug that can necessarily
be fixed quickly, but a piece of technical debt that maintainers should
be aware of.

A porting guide is provided in the GTK 3 documentation:
https://developer.gnome.org/gtk3/stable/migrating.html

Some libraries (for example libgtkspell0) expose GTK as part of their
API/ABI, in which case removing the deprecated dependency requires
breaking API/ABI. For these libraries, in many cases there will already
be a corresponding GTK 3 version (for example libgtkspell3-3-0), in which
case the GTK 2-based library should probably be deprecated or removed
itself. If there is no GTK 3 equivalent, of a GTK 2-based library,
maintainers should talk to the dependent library's upstream developers
about whether the dependent library should break API/ABI and switch
to GTK 3, or whether the dependent library should itself be deprecated
or removed.

A few packages extend GTK 2 by providing plugins (theme engines, input
methods, etc.) or themes, for example ibus and mate-themes. If these
packages deliberately support GTK 2 even though it is deprecated, and
they also support GTK 3, then it is appropriate to mark this mass-filed
bug as wontfix for now. I have tried to exclude these packages from
the mass-bug-filing, but I probably missed some of them.

Regards,
    smcv

Message #12 received at 967284@bugs.debian.org (full text, mbox, reply):

From: Michalis Kamburelis <michalis.kambi@gmail.com>

To: 967284@bugs.debian.org

Subject: Re: castle-game-engine: depends on deprecated GTK 2

Date: Sun, 9 Aug 2020 23:01:12 +0200

[Message part 1 (text/plain, inline)]

Upgrade to GTK3 is planned.

It is a task inside TCastleWindowBase class (a window with OpenGL context).
The class is implemented by various platform-specific backends, in
particular the default backend on Linux right now uses GTK2 indeed.

The upgrade is not a big job. We just use GTK to easily open a window, show
the menu bar, toggle fullscreen. In the end, most of the things done by
Castle Game Engine just happen inside the big OpenGL area that fills almost
all window space, so they are completely independent from GTK.

Although I do not plan the upgrade to GTK3 in the immediate moment.
Probably not in 2020, and not for the upcoming Castle Game Engine 7.0
release. It will happen most likely in 2021. Let me know if you would like
me to prioritize this task more.

Oh, and if anyone would like to help, you're most welcome. The point of
integration between Castle Game Engine and GTK is quite localized in code
-- see the src/window/gtk code path (view on GitHub:
https://github.com/castle-engine/castle-engine/tree/master/src/window/gtk
). Pull requests are welcome :) You can implement GTK3 backend there, as
parallel to existing GTK2, so you will be able to experiment with stuff
without fear of breaking the GTK2 version.

Regards,
Michalis

[Message part 2 (text/html, inline)]

Message #19 received at 967284@bugs.debian.org (full text, mbox, reply):

From: Bastian Germann <bage@debian.org>

To: 967284@bugs.debian.org, michalis.kambi@gmail.com

Subject: Re: castle-game-engine: depends on deprecated GTK 2

Date: Wed, 27 Sep 2023 11:45:15 +0200

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.

Message #24 received at 967284@bugs.debian.org (full text, mbox, reply):

From: Peter B <peter@pblackman.plus.com>

To: Bastian Germann <bage@debian.org>, 967284@bugs.debian.org, Project developers <pkg-pascal-devel@alioth-lists.debian.net>

Cc: michalis.kambi@gmail.com

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

Date: Wed, 27 Sep 2023 11:16:36 +0100

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

Message #29 received at 967284@bugs.debian.org (full text, mbox, reply):

From: Michalis Kamburelis <michalis.kambi@gmail.com>

To: peter@pblackman.plus.com, 967284@bugs.debian.org

Cc: Bastian Germann <bage@debian.org>, Project developers <pkg-pascal-devel@alioth-lists.debian.net>

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

Date: Wed, 27 Sep 2023 23:54:50 +0200

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@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
>

Message #38 received at 967284@bugs.debian.org (full text, mbox, reply):

From: Jeremy Bícha <jbicha@debian.org>

To: 977295@bugs.debian.org, 967246@bugs.debian.org, 967259@bugs.debian.org, 967267@bugs.debian.org, 967271@bugs.debian.org, 967284@bugs.debian.org, 967286@bugs.debian.org, 967287@bugs.debian.org, 967291@bugs.debian.org, 967295@bugs.debian.org, 967297@bugs.debian.org, 967304@bugs.debian.org, 967305@bugs.debian.org, 967315@bugs.debian.org, 967317@bugs.debian.org, 967322@bugs.debian.org, 967330@bugs.debian.org, 967348@bugs.debian.org, 967372@bugs.debian.org, 967375@bugs.debian.org, 967379@bugs.debian.org, 967381@bugs.debian.org, 967384@bugs.debian.org, 967405@bugs.debian.org, 967406@bugs.debian.org, 967408@bugs.debian.org, 967409@bugs.debian.org, 967411@bugs.debian.org

Subject: raise severity of gtk2 bugs

Date: Wed, 7 Jan 2026 20:18:00 -0500

Control: severity -1 serious

As announced [1], we are trying to remove gtk2 from forky. Therefore,
I am raising the severity of this issue.

[1] https://lists.debian.org/debian-devel/2026/01/msg00090.html

On behalf of the Debian GNOME team,
Jeremy Bícha

Send a report that this bug log contains spam.