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

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

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

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 <peter@pblackman.plus.com> napisał(a):

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

( 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

Hi Michalis,

On Mon, 2026-02-09 at 03:03 +0000, Michalis Kamburelis wrote:
...
Now we have fp-units-gtk3 on debian, so maybe you can use them?
Maybe with new version of Lazarus you can do this easier. Please note
that Lazarus itself is not really usable with GTK3 WS, but many
applications will run just fine.

According to some upstream tickets, we may expect Lazarus 5.0 by end of
year.
-- 
Cheers,
Abou Al Montacir