- Package:
- src:c-evo-dh
- Source:
- src:c-evo-dh
- Submitter:
- Bastian Germann
- Date:
- 2026-03-14 22:13:02 UTC
- Severity:
- normal
- Tags:
This package has Build-Depends on GTK 2 (libgtk2.0-dev), or produces binary packages with a Depends on GTK 2. Honestly, this package should not have entered Debian with gtk2 in 2023. 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. Please consider switching to lcl=qt5 to build with qt5 interface. Please rename c-evo-dh-gtk2 to c-evo-dh when implementing this. We really do not need to know the toolkit that it uses by looking at the pkg name. I would gladly sponsor this.
Hi Bastian, Lazarus can build packages against various toolkits, and if more than one is viable, building those gives users some choice, as they all have various quirks. The toolkit in the package name allows that differentiation. C-evo-dh will build against all supported Lazarus toolkits, however, gtk3 & fpgui builds crash on startup, and qt5 & qt6 have corrupted graphics. gtk2 is the only Linux toolkit version that currently runs OK. C-evo-dh has been intentionally packaged to allow co-installation of multiple front-ends. I will certainly include others when they become viable. I tested the Qt6 build today with Lazarus 3.0RC1, but have the same display issues as with Qt5. gtk3 is being worked on upstream. That may become a possibility. Cheers, Peter
Hi Peter, please bring this issue to the attention of upstream to get it working using gtk3 or qt. I agree with Bastian that we should avoid making the GTK2 problem space bigger. really name. one is viable, quirks. graphics. multiple front-ends. display issues as with Qt5.
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
Do we have a fix for this? It seems we need to either re-write or drop ClassicLadder.
Es gibt eine Familienspende in Höhe von 1.850.000,00 USD von Cheng Charlie Saephan. Bitte antworten Sie für weitere Informationen. Denken Sie daran, Ihrer Familie und den Bedürftigen in Ihrer Umgebung Gutes zu tun. Dies ist bereits der zweite Versuch, Sie zu erreichen. Bitte antworten Sie für weitere Details.
Es gibt eine Familienspende in Höhe von 1.850.000,00 USD von Cheng Charlie Saephan. Bitte antworten Sie für weitere Informationen. Denken Sie daran, Ihrer Familie und den Bedürftigen in Ihrer Umgebung Gutes zu tun. Dies ist bereits der zweite Versuch, Sie zu erreichen. Bitte antworten Sie für weitere Details.
I have tried both the gtk2 version and the qt5 version and contrary to what you claim, the gtk2 version is completely broken with black artifacts flickering on the screen while the qt5 version is playable. This is with XFCE (X11) on an arm64 machine. The debdiff of my qt5 experiment is attached (not a patch for the actual package) to demonstrate how I have built it.
I'm surprised to hear that. Its working perfectly for me. There a over a dozen Debian users according to Popcon, a handful on Arch, probably a load more on Ubuntu & Mint, but nobody has every mentioned anything like this. Maybe its something to do with the graphics on your arm64 machine? I expect most users will be using amd64. Its not good enough, and still a bit of a mess. There are still issues with icon borders and ghosting (see attached screenshots) Whereas the Gtk2 version is a near perfect replica of the Windows version. I did however make some progress with the graphics corruption on the main screen (fixed in version 2.9) Main screen scrolling is very sluggish, and shows very high CPU usage. Maybe users with modern machines could live with that, but this app was originally developed in the era of the Pentium 4. A key feature is that is should be easily playable on low spec hardware. Worst problem with Qt is that the sprite flashing of the selected unit is broken. While this may not matter re an isolated unit, if there are several units of the same type on adjacent tiles, its impossible to know which one has been selected, making the game unplayable. (No noticeable difference between Qt5 or Qt6 builds)
Please note that this package lacks the necessary Build-Depends now that lcl-gtk2 was dropped. Please switch to a different widgetset.