Replacing Wesnoth's GUI

[Pentarctagon]

Based on the discussion here, the best thing we could try and do to significantly improve Wesnoth overall as well as its maintainability in the longer term would be to replace Wesnoth's current custom GUI toolkit with an external framework that we then wouldn't need to maintain ourselves.

To start on the path to accomplishing that, we need to decide on two things up front:

1. Which GUI framework should we switch to?
2. What needs to be done in Wesnoth's existing codebase beforehand to make this transition easier/simpler?

For (1), suggestions made in the previous thread were:

• TGUI
• Setting up the existing C++ codebase as a GDNative/GDExtension module for Godot, and then only making use of Godot's rendering/display functionality.

Are there any other suggestions that anyone has? Keeping in mind as well that whatever GUI framework we choose will also need to be able to handle displaying Wesnoth's existing translations, as well as have support for HiDPI displays and Apple Silicon.

For (2): the general statement made so far is essentially to decouple the current GUI from places in the current codebase where it really shouldn't be used/needed. However, that's not specific enough for most people to be able to work on that. So:

• What does decoupling the code mean here, more detailed/technically?
• Which areas (or even specific files) would need to be worked on?

[loonycyborg]

There is another framework to consider, namely Qt. QtQuick Controls is themable enough to be considered for game use.

[Lord-Knightmare]

Ruling out Apache-2.0 license (I dont think it is compatible with GPLv2) and searching up possible alternates (for TGUI), I guess more suggestions would be:

• imgui - sfml https://github.com/eliasdaler/imgui-sfml
• imgui https://github.com/ocornut/imgui
• SFGUI https://github.com/TankOs/SFGUI

There's a 4th called GUILite which has a license not compatible but linking here for reference https://github.com/idea4good/GuiLite.

[Pentarctagon]

There is another framework to consider, namely Qt. QtQuick Controls is themable enough to be considered for game use.

I've heard mixed things about Qt, though I'm not at all familiar with it myself. It would definitely be a very heavy dependency to add though.

Ruling out Apache-2.0 license (I dont think it is compatible with GPLv2) and searching up possible alternates (for TGUI), I guess more suggestions would be:

• imgui - sfml https://github.com/eliasdaler/imgui-sfml
• imgui https://github.com/ocornut/imgui
• SFGUI https://github.com/TankOs/SFGUI

There's a 4th called GUILite which has a license not compatible but linking here for reference https://github.com/idea4good/GuiLite.

imgui would be ruled out since from their README it says: "It outputs optimized vertex buffers that you can render anytime in your 3D-pipeline enabled application." which... we don't have. Maybe using SFML with it would let that work? I'm not familiar with it though.

Also not familiar with SFGUI either.

[Elvish_Hunter]

A possible problem I see with SFGUI might be its support status. The last commit in the repository happened on the 22nd of September 2020, which might mean that nobody's currently working on it.

[Pentarctagon]

Apple Silicon support as well would be a big question.

[doofus-01]

There is another framework to consider, namely Qt. QtQuick Controls is themable enough to be considered for game use.

I've heard mixed things about Qt, though I'm not at all familiar with it myself. It would definitely be a very heavy dependency to add though.

From what I've read (mostly old stackoverflow posts), the issues with Qt are that it is LGPL, is C++, it is too big and inconvenient to compile, and most common IDEs don't recognize some things. Being too big and bloated sounds bad, but it also sounds like something that could be discovered before too much time is sunk into it. Was there something else wrong with it?

It would have the advantage of not being obscure or unmaintained. Someone learning it for Wesnoth development wouldn't be completely wasting their time, and outsiders with Qt experience might be willing to help with Wesnoth development.

Also, newer versions apparently support Apple Silicon.

[Pentarctagon]

The main other thing that I'd seen some articles about (not particularly recently anymore) is that in an effort to boost their profitability they're delaying LTS releases for their non-commercial version. Beyond that, a more minor concern would be if there'd be any issue with linux packaging at some point, given we wouldn't be able to just stay on the same version of Qt indefinitely.

[Celtic_Minstrel]

For (2): the general statement made so far is essentially to decouple the current GUI from places in the current codebase where it really shouldn't be used/needed. However, that's not specific enough for most people to be able to work on that. So:

• What does decoupling the code mean here, more detailed/technically?
• Which areas (or even specific files) would need to be worked on?

I think the general approach would be: keep the internal API as similar as possible and keep the parsing code unchanged, while gutting all the actual GUI classes and making them thin wrappers around an equivalent class from the chosen library.

I'm not 100% sure if keeping the parsing code completely unchanged is possible, but I think it might be. Parsing code in this case refers to the builder_widget_name classes for GUI2 (and probably a few other supporting bits and pieces, like window_builder.cpp) and I believe theme.cpp (or at least part of it) for ThemeWML, plus probably help_topic_generators.cpp for HelpWML.

There is the alternative possibility of rewriting the parsing code from scratch to consume the same WML format. I don't know if that would be easier than trying to keep the existing code intact. Actually, I think it's more likely to be harder, but if someone wants to try, they're welcome to. (Note that, while I'm calling it a "parser", it's actually consuming already-parsed WML and converting it to a widget tree. So, I'm not sure if "parser" is the best term.)

In some cases there may be a need to make minor changes to the C++ API for GUI2 widgets. This isn't really a problem since Wesnoth itself is the only consumer of that API (it's not a public API from our perspective). We should at least take great pains to avoid changing the Lua API, though.

I'm not sure what we would do with the GUI2 event distributor. If we can get rid of it entirely, that's not the worst outcome (its inability to interoperate with non-GUI2 events is the reason we haven't been able to switch the in-game UI to GUI2), but I suspect it may have desirable features, so… I'm not sure getting rid of it is the best choice. Another possibility would be to get rid of the non-GUI2 event distributor… but the GUI2 is literally built on top of the non-GUI2 one so I'm not sure how viable that is.

[Pentarctagon]

I'm not sure what we would do with the GUI2 event distributor. If we can get rid of it entirely, that's not the worst outcome (its inability to interoperate with non-GUI2 events is the reason we haven't been able to switch the in-game UI to GUI2), but I suspect it may have desirable features, so… I'm not sure getting rid of it is the best choice. Another possibility would be to get rid of the non-GUI2 event distributor… but the GUI2 is literally built on top of the non-GUI2 one so I'm not sure how viable that is.

Maybe I have the wrong idea in my head about this, but wouldn't event distributing generally be handled by the new GUI framework? I can't imagine an external framework that shows UI elements but then says "alright, now it's your job to figure out what you clicked on" and similar would be especially useful.

[doofus-01]

The main other thing that I'd seen some articles about (not particularly recently anymore) is that in an effort to boost their profitability they're delaying LTS releases for their non-commercial version. Beyond that, a more minor concern would be if there'd be any issue with linux packaging at some point, given we wouldn't be able to just stay on the same version of Qt indefinitely.

I wasn't sure what to make of that, but for what it's worth, KDE doesn't seem too concerned (unofficial commentary here, and apparently this wasn't worth updating).

On the opposite end of the spectrum from Qt is Nuklear https://github.com/Immediate-Mode-UI/Nuklear
I'm not able to judge if it is lacking something vital though.

[Celtic_Minstrel]

Maybe I have the wrong idea in my head about this, but wouldn't event distributing generally be handled by the new GUI framework? I can't imagine an external framework that shows UI elements but then says "alright, now it's your job to figure out what you clicked on" and similar would be especially useful.

It might be. In that case we'd need to wire everything into the new event distributor for whatever external framework we choose.

Somewhere in here is probably an argument in favour of choosing TGUI as the framework – it hinges on the event source. Wesnoth is already built on SDL as a source of events, and TGUI is apparently configurable to also use SDL as the event source. On the other hand, if I understand correctly, both Godot and Qt are themselves an event source, so they clash somewhat with our use of SDL. That's not to say we couldn't use them, but I think we'd need to replace more code to use them compared to if we went with TGUI (or any other library built on SDL). So, the workload seems higher.

[Pentarctagon]

For Godot and Qt I think we wouldn't directly be using SDL at all? They're much larger, fuller featured frameworks, so we'd probably be using the framework functionality rather than SDL directly anymore.

And yeah, at some point it does also come down to how many people would be willing to help out with moving to a different GUI framework. I suspect that there are more people who are knowledgeable of Qt or Godot than SDL (so there'd be more people who'd know the framework Wesnoth uses and would be able to contribute) and they both have additional functionality we could make use of in the future (such as using Qt or Godot for playing audio), but if it's too much work to realistically be able to complete then it's moot.

[Celtic_Minstrel]

For Godot and Qt I think we wouldn't directly be using SDL at all? They're much larger, fuller featured frameworks, so we'd probably be using the framework functionality rather than SDL directly anymore.

Which is exactly why such a move would be far more work. There's more code that would need to be ripped out and replaced.

[octalot]

The game needs to be playable at every stage, otherwise we'll end up with the same situation as the AR Branch. Compile-time selection of which UI Toolkit to use is fine, but there has to be an overlap period where the master branch can be built with either toolkit, and the result is something that's fun to play. For setting up the CI, I think the compile-time selection should be something that's configurable in CMake and SCons, not something that needs code changes.

For the goal of performance, we need to port (or rewrite) the terrain and map rendering to the new toolkit. I think "replace the GUI2 parts with the new toolkit" and "port the game board to the new toolkit" might be separate projects.

I disagree with the idea of building a GUI2 compatibility wrapper around the new toolkit, because we'd end up with code that needs maintainers to understand both toolkits. To make it accessible to new developers and better on the CVs of old developers, I think the new GUI should be designed and created using the tools of the new toolkit, even if that means we no longer support ThemeWML or the GUI2-in-Lua features. Having some wrappers as a workaround to satisfy the "playable at every stage" requirement is likely to happen, but those should be temporary - during the overlap period, the GUI2 code might itself depend on the new toolkit's data types.

Getting SDL dependencies out of the non-GUI code sounds like common work that would be needed for any toolkit, and would probably give us better code even if we stay with SDL. Everything here sounds like a lot of work.

Gnome's toolkit is another possibility (I believe it's called adwaita, don't know more than that).