Replacing Wesnoth's GUI

[Pentarctagon]

Is it practical to need to have master branch buildable with both the current and new GUI frameworks at the same time? That sounds like a lot of time would be spent on that, rather than on actually porting to the new framework - a_r's issue was that it was merged into the master branch while still incomplete, so having only the new framework available for use but on a separate feature branch until it's ready sounds like a more practical way to address that.

[Celtic_Minstrel]

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.

I think the GUI2 compatibility wrapper can actually make the work easier, because you don't need to change any (or much) of the code that actually uses the widgets. However, keeping GUI2 compatibility wrappers at the C++ step and keeping GUI2 WML / ThemeWML parsing are, I believe, two independent things, and you could easily keep the latter while scrapping the former. It's hard to say how this plays out with the Lua GUI2 API though. I think it could be maintained without external changes but I'm not sure how easy it would be.

Is it practical to need to have master branch buildable with both the current and new GUI frameworks at the same time? That sounds like a lot of time would be spent on that, rather than on actually porting to the new framework - a_r's issue was that it was merged into the master branch while still incomplete, so having only the new framework available for use but on a separate feature branch until it's ready sounds like a more practical way to address that.

If choosing an SDL-backed framework (such as TGUI) the replacement could probably be done patchwork, a little at a time.

For something else I imagine it would be difficult but not necessarily impossible to permit building with either framework using a compile-time flag.

[octalot]

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.

Possible different plan - during the overlap I think we might build two executables, one that uses SDL and one that uses the new toolkit; hopefully most of the .cpp files will only need to be compiled once.

Is it practical to need to have master branch buildable with both the current and new GUI frameworks at the same time? That sounds like a lot of time would be spent on that, rather than on actually porting to the new framework - a_r's issue was that it was merged into the master branch while still incomplete, so having only the new framework available for use but on a separate feature branch until it's ready sounds like a more practical way to address that.

I haven't looked at the a_r code itself, and I don't want to spend the time learning that code, so please correct me if I'm making incorrect assumptions here. I'm working on the assumption that it would have needed work to get to a playable state, but that most of the changes on the a_r branch were untested cherry-picks of the development that was happening on the stable branch, and so it had two separate sources of new bugs.

I think feature branches help, and initially a feature branch would only need to build with the new toolkit. However, classes can be refactored in the branch to be less dependent on the GUI, while development continues on the same classes in master, and someone then has to reconcile the differences. During that phase the differences between the branches cause work for someone. If there are bugs on the new toolkit branch that aren't reproducible on master, someone needs to spend time working out if they're caused by the toolkit or by a bad merge. Improvements that reduce dependency on the GUI can be cherry-picked back to master, but there's still a difference that causes extra work for the feature branch. I agree with your "that sounds like a lot of time would be spent on that", but think it gets spent somewhere anyway.

There has to come time when all changes to master have to be tested with the new toolkit, and responsibility for that testing is pushed onto the relevant PR's author. At that point the new toolkit's branch becomes de facto master, even if it's not called "master". That reduces the work for the new toolkit team, so I'd suggest it happens when:

• single player works with the new toolkit and is enjoyable to play for most campaigns (okay to break anything that has custom dialogs and have bad [story] screens)
• most already-installed add-ons work with the new toolkit (campaigns, eras, but not themes)
• everything is testable in at least one of the toolkits (the multiplayer lobby works, creating and joining games works, but it's ok to say "those only work in the SDL build, and then you get a blank screen in-game, so connect to the game with an old version of the client to see if it worked")
• everything not mentioned above works in at least one of the toolkits (ok to say "for installing add-ons use the SDL build")

At that point, I think we need to be able to build both a (new toolkit executable) and an (everything works executable) from the same Git commit, and we'd be in the overlap period. The entry point of the executable is heavily tied to the toolkit, the new toolkit would need a rewritten version of src/wesnoth.cpp; so it might be better to build two executables in a single build instead of needing a compile-time choice.

I think the GUI2 compatibility wrapper can actually make the work easier, because you don't need to change any (or much) of the code that actually uses the widgets.

If we do that, how do we avoid getting the influence of GUI2 design into the new code, and thus ending up with code which needs understanding of both toolkits to maintain?

[Pentarctagon]

I think feature branches help, and initially a feature branch would only need to build with the new toolkit. However, classes can be refactored in the branch to be less dependent on the GUI, while development continues on the same classes in master, and someone then has to reconcile the differences. During that phase the differences between the branches cause work for someone. If there are bugs on the new toolkit branch that aren't reproducible on master, someone needs to spend time working out if they're caused by the toolkit or by a bad merge. Improvements that reduce dependency on the GUI can be cherry-picked back to master, but there's still a difference that causes extra work for the feature branch. I agree with your "that sounds like a lot of time would be spent on that", but think it gets spent somewhere anyway.

There has to come time when all changes to master have to be tested with the new toolkit, and responsibility for that testing is pushed onto the relevant PR's author. At that point the new toolkit's branch becomes de facto master, even if it's not called "master". That reduces the work for the new toolkit team, so I'd suggest it happens when:

• single player works with the new toolkit and is enjoyable to play for most campaigns (okay to break anything that has custom dialogs and have bad [story] screens)
• most already-installed add-ons work with the new toolkit (campaigns, eras, but not themes)
• everything is testable in at least one of the toolkits (the multiplayer lobby works, creating and joining games works, but it's ok to say "those only work in the SDL build, and then you get a blank screen in-game, so connect to the game with an old version of the client to see if it worked")
• everything not mentioned above works in at least one of the toolkits (ok to say "for installing add-ons use the SDL build")

At that point, I think we need to be able to build both a (new toolkit executable) and an (everything works executable) from the same Git commit, and we'd be in the overlap period. The entry point of the executable is heavily tied to the toolkit, the new toolkit would need a rewritten version of src/wesnoth.cpp; so it might be better to build two executables in a single build instead of needing a compile-time choice.

I feel like this would be more relevant if there were frequent changes being made to the toolkit/UI classes, which there really aren't.

[Pentarctagon]

(not sure where this went in my previous post)

I haven't looked at the a_r code itself, and I don't want to spend the time learning that code, so please correct me if I'm making incorrect assumptions here. I'm working on the assumption that it would have needed work to get to a playable state, but that most of the changes on the a_r branch were untested cherry-picks of the development that was happening on the stable branch, and so it had two separate sources of new bugs.

The issue with a_r was that it was merged into the master branch while known to be incomplete, in an effort to force other people to take a look at and help solve a problem that the author of a_r wasn't able to solve. It was never in any stable branch or feature branch. The current old_master_20181015 is the result of that, before the mass revert that needed to be done after it remained unplayable on the master branch for multiple months while other people continued adding their own commits on top of something that wasn't playable.

Some background: #3538, #3603, #3614

So my thought is that it'd be easiest to have a separate feature branch for the new GUI framework implementation, which we could even put out as a beta release separate from the regular stable/dev releases for people to try out, rather than needing to try and support two GUI frameworks simultaneously within the same codebase.

[Celtic_Minstrel]

I think the GUI2 compatibility wrapper can actually make the work easier, because you don't need to change any (or much) of the code that actually uses the widgets.

If we do that, how do we avoid getting the influence of GUI2 design into the new code, and thus ending up with code which needs understanding of both toolkits to maintain?

All the "new code" is internal to the GUI2 widget classes in that approach. If there's something incompatible between the GUI2 design and the new toolkit's design, then… you'd probably just need to break the external API to match the new code. I think it's still less work if only a few things break in the external C++ GUI2 API, compared to stripping it all out and replacing it with a new toolkit.

I'm glad you mentioned StoryWML, because that's another place where the WML story screen definition could be parsed directly into a layout without going through any intermediate representation (currently the WML definition has to be applied to the GUI2 dialog created via GUI2 WML). Another example of this is CreditsWML.

[loonycyborg]

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

GNOME's toolkit is GTK, it would be the most natural choice honestly. We're already using Pango which is one of GNOME libs. Though GTK purposefully doesn't have any support for mobile platforms, so we'd have to have a separate GUI component for each targeted mobile platform then, as GTK devs think that it's the way to go. They're not of high opinion about Qt's general mobile support.

Adwaita is the name of GNOME's default GUI theme, and were wesnoth go GTK we'd have own theme for the GUI instead.

[Pentarctagon]

I vaguely remember reading that GTK's Windows (or cross platform support in general) isn't that great - is that no longer the case?

[Celtic_Minstrel]

I don't feel that GTK is a natural choice; first of all it's Glib-based if I recall correctly, which I feel makes it a poor choice for a C++ program, and also that lack of mobile support seems like it kind of defeats the point if we want mobile support. I don't like Qt either, mainly because of its extra code generation step. Furthermore, both GTK and Qt are full-featured UI libraries designed for making native applications, while I think we should be looking at something more game-oriented.

(I realize we're also using Pango and Cairo that are also Glib-based. I'd prefer not to use them either, but as far as I know there are no existing alternatives, which is quite unfortunate.)

[loonycyborg]

I vaguely remember reading that GTK's Windows (or cross platform support in general) isn't that great - is that no longer the case?

Seems GTK has first rate upstream support both for windows and mac(but purposefully no mobile). Also thanks to MSYS2 it would be easy for me to handle building against it on windows. Myself I have more experience working with Qt than with GTK, though I have conflicting feelings about Qt's current direction even though I favored it in the past.