Replacing Wesnoth's GUI
Moderator: Forum Moderators
- Pentarctagon
- Project Manager
- Posts: 5602
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Replacing Wesnoth's GUI
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:
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:
To start on the path to accomplishing that, we need to decide on two things up front:
- Which GUI framework should we switch to?
- What needs to be done in Wesnoth's existing codebase beforehand to make this transition easier/simpler?
- 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.
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?
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
take one down, patch it around
-2,147,483,648 little bugs in the code
- loonycyborg
- Windows Packager
- Posts: 297
- Joined: April 1st, 2008, 4:45 pm
- Location: Russia/Moscow
Re: Replacing Wesnoth's GUI
There is another framework to consider, namely Qt. QtQuick Controls is themable enough to be considered for game use.
"meh." - zookeeper
- Lord-Knightmare
- Discord Moderator
- Posts: 2377
- Joined: May 24th, 2010, 5:26 pm
- Location: Somewhere in the depths of Irdya, gathering my army to eventually destroy the known world.
- Contact:
Re: Replacing Wesnoth's GUI
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
Creator of "War of Legends"
Creator of the Isle of Mists survival scenario.
Maintainer of Forward They Cried
User:Knyghtmare | My Medium
Creator of the Isle of Mists survival scenario.
Maintainer of Forward They Cried
User:Knyghtmare | My Medium
- Pentarctagon
- Project Manager
- Posts: 5602
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: Replacing Wesnoth's GUI
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.loonycyborg wrote: ↑March 22nd, 2022, 7:01 pm There is another framework to consider, namely Qt. QtQuick Controls is themable enough to be considered for game use.
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.Lord-Knightmare wrote: ↑March 22nd, 2022, 7:12 pm 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:
There's a 4th called GUILite which has a license not compatible but linking here for reference https://github.com/idea4good/GuiLite.
- imgui - sfml https://github.com/eliasdaler/imgui-sfml
- imgui https://github.com/ocornut/imgui
- SFGUI https://github.com/TankOs/SFGUI
Also not familiar with SFGUI either.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
take one down, patch it around
-2,147,483,648 little bugs in the code
- Elvish_Hunter
- Posts: 1585
- Joined: September 4th, 2009, 2:39 pm
- Location: Lintanir Forest...
Re: Replacing Wesnoth's GUI
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.
Current maintainer of these add-ons, all on 1.16:
The Sojournings of Grog, Children of Dragons, A Rough Life, Wesnoth Lua Pack, The White Troll (co-author)
The Sojournings of Grog, Children of Dragons, A Rough Life, Wesnoth Lua Pack, The White Troll (co-author)
- Pentarctagon
- Project Manager
- Posts: 5602
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: Replacing Wesnoth's GUI
Apple Silicon support as well would be a big question.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
take one down, patch it around
-2,147,483,648 little bugs in the code
Re: Replacing Wesnoth's GUI
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?Pentarctagon wrote: ↑March 22nd, 2022, 7:41 pmI'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.loonycyborg wrote: ↑March 22nd, 2022, 7:01 pm There is another framework to consider, namely Qt. QtQuick Controls is themable enough to be considered for game use.
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.
BfW 1.12 supported, but active development only for BfW 1.13/1.14: Bad Moon Rising | Trinity | Archaic Era |
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
- Pentarctagon
- Project Manager
- Posts: 5602
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: Replacing Wesnoth's GUI
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.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
take one down, patch it around
-2,147,483,648 little bugs in the code
- Celtic_Minstrel
- Developer
- Posts: 2292
- Joined: August 3rd, 2012, 11:26 pm
- Location: Canada
- Contact:
Re: Replacing Wesnoth's GUI
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.Pentarctagon wrote: ↑March 22nd, 2022, 6:36 pm 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'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
- Project Manager
- Posts: 5602
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: Replacing Wesnoth's GUI
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.Celtic_Minstrel wrote: ↑March 27th, 2022, 3:39 am 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.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
take one down, patch it around
-2,147,483,648 little bugs in the code
Re: Replacing Wesnoth's GUI
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).Pentarctagon wrote: ↑March 26th, 2022, 3:40 pm 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.
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.
BfW 1.12 supported, but active development only for BfW 1.13/1.14: Bad Moon Rising | Trinity | Archaic Era |
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
- Celtic_Minstrel
- Developer
- Posts: 2292
- Joined: August 3rd, 2012, 11:26 pm
- Location: Canada
- Contact:
Re: Replacing Wesnoth's GUI
It might be. In that case we'd need to wire everything into the new event distributor for whatever external framework we choose.Pentarctagon wrote: ↑March 27th, 2022, 3:49 am 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.
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
- Project Manager
- Posts: 5602
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: Replacing Wesnoth's GUI
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.
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.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
take one down, patch it around
-2,147,483,648 little bugs in the code
- Celtic_Minstrel
- Developer
- Posts: 2292
- Joined: August 3rd, 2012, 11:26 pm
- Location: Canada
- Contact:
Re: Replacing Wesnoth's GUI
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.Pentarctagon wrote: ↑March 28th, 2022, 2:15 am 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.
Re: Replacing Wesnoth's GUI
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).
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).