Support for using the Qt & QtQuick gui toolkit

[fabi]

Qt is the gui toolkit on which the KDE Desktop & Applications are based.
It overs a rich pool including all kinds of widgets.

QtQuick can be used to access Qt's functionality by using a declarative language called QML.

Currently Wesnoth's portability is mostly limited by the dependency on the SDL library.
SDL is available on many platforms.

Qt might not be available on every platform SDL is,
but it covers most of Wesnoth's targets:

Spoiler:

Linux/Unix/X Window System (Solaris, HP-UX, AIX, ...)
Windows
MacOSX (Carbon & Cocoa)
Windows CE & Windows Mobile
Android
iOS
Pandora
And some more

Have a look at the code base:
GitHub Wesnoth Qt Branch

Additional requirements for building in Ubuntu:

Code: Select all

apt-get install qml-module-qtquick-dialogs qml-module-qtquick-controls libqt5quick5 qtdeclarative5-qtquick2-plugin qtdeclarative5-dialogs-plugin qtdeclarative5-dev

[lipk]

Hmm, did you think this over? The utilization of SDL in Wesnoth goes far beyond just buttons and sliders, as I presume you know as well. Ditching SDL for Qt might not only be a tremendous effort, but also an unbeneficial one considering that Qt is not exactly designed with game development in mind.

Android

I'm not sure about this. Last time I checked they only had some unofficial pre-alpha stuff.

[fabi]

Hmm, did you think this over?

Yes, I spent a lot of thoughts into this, since a long time.
The lack of a feature complete gui toolkit isn't haunting the Wesnoth project since yesterday.

The utilization of SDL in Wesnoth goes far beyond just buttons and sliders, as I presume you know as well.

Well, we use SDL's event and drawing system, the multimedia features (loading and playing music, image file loading) and some more but buttons and sliders are not produced by SDL direclty,
as I presume you know as well.

Ditching SDL for Qt...

This is not the proposal.
I compared SDL's and Qt's portability to argue that adding Qt to the dependencies is not reducing Wesnoth's portability much.

... might not only be a tremendous effort, ...

Maybe.
But that is not much of my concern right now.

There are some software projects using qt and sdl happily together.

... but also an unbeneficial one...

Well, I consider having a feature complete GUI toolkit beneficial enough alone.

... considering that Qt is not exactly designed with game development in mind.

At this year's FOSDEM we had a talk in our game development room held by a boy from the qt team,
praising Qt's excellent qualities when it comes to game development.

Qt comes with joystick/gamepad support.
There is a system that can be used for timed events like we use SDL's ticks.
So far I consider Qt quite well suited for usage in Wesnoth.

But I am not stuck to Qt.
I guess gtk+ would surely do good as well.
Or maybe some more higher level tool which comes with a ready to use game engine.

Suggestions are welcomed.

Android

I'm not sure about this. Last time I checked they only had some unofficial pre-alpha stuff.

Qt 5.3 (Already reached Ubuntu) comes with Android support. It is not labeled alpha or beta anymore.
The port is still quite new but "mostly completed".

[iceiceice]

Here are some reasons I think Qt is worth considering / experimenting with:

• GUI2 lacks some important widgets and related features. It lacks menus, context menus, modal dialogs for instance.
• It's pretty hard to add stuff like this to GUI2. You have to read quite a bit of GUI2 implementation details to be able to add new widgets or add new functionality to existing widgets.
  
  For instance it took me several days worth of work to make GUI2 text boxes automatically render hyperlinks and make them clickable -- this required editing like 5 or 6 core classes, all the way down to font::ttext where I had to add pango library calls to dereference mouse clicks to text locations... It's possible but I would really be surprised if there were an easier way. A mainstream widget toolkit seems more likely to support features like this out of the box, and there are many other things like this that would be nice to have (and which qt seems to provide).
  
  As another example, Aquileia tried to make a "numeric text box" to support Dugi's add-on reviews project... but since making a new GUI2 widget is pretty hard I think this project was not completed after a month and was eventually abandoned (?)
  
  Has anyone besides mordante successfully made a new GUI2 widget? The only other person with special knowledge of GUI2 right now seems to be shadowm.
• Even if we do write all our own widget code, it might get like 80-90% of the way there but realistically it's going to be a bit buggy. Most users have pretty exacting expectations of how widgets should behave, because of dominant design etc. It's really hard to get all the details right, and especially to do dynamic layout stuff. So outsourcing this code seems pretty attractive. It's frustrating to make a dialog and have to work around obscure bugs in the widget library.
  
  IMO it goes back to "we are (mostly) not professional programmers, better to avoid reinventing the wheel"
• Qt is widely used and widely available. This makes learning to use Qt a transferrable skill. Learning to use GUI2 is useful only for wesnoth. More people might be interested to contribute code to wesnoth's UI if it's based on Qt.
• Qt is developed and supported by an enormous team with tons of documentation, code examples, an entire ide. The GUI2 documentation is not just good, it is extremely good, remarkably good especially in comparison to the rest of the project, but there can't really be a competition.
• GUI2 development doesn't seem to be moving fast enough to support the kinds of front-end UI overhauls that many people have expressed interest in. For instance there's this thread from nearly 6 years ago:
  
  http://forums.wesnoth.org/viewtopic.php?f=9&t=24598
  
  Or this recent thread:
  
  http://forums.wesnoth.org/viewtopic.php?f=23&t=41238
  
  All of these ideas are somewhat hampered by limitations of ThemeWML / GUI1. There don't seem to be any serious plans to replace ThemeWML with GUI2, and it's actually not clear that GUI2 is even designed with this in mind. It seems quite plausible to me that if ThemeWML were replaced with Qt then we could rapidly implement these different ideas using ready-made widgets. We would definitely not be the first game to use Qt for hud overlays like this.
• Qt appears to be known to work in games using SDL, in games using OpenGL, and in games using SDL and OpenGL together... at least there many internet pages describing this, troubleshooting various problems, etc. Nurupo made some comments on irc recently about ease of interaction between Qt and OpenGL. So hopefully Qt is a good choice in the interest of not becoming a stumbling block for the SDL2 / SDL_gpu project.
  
  Overall while traditionally games implement all their own UI to get their own look and feel, it seems like it might be a trend now to try to skip this and instead put a skin on an established UI, to save time and focus on more important stuff.

These are really arguments for using a mainstream external widget library, I don't actually know very much about Qt itself. I do know that in the last 6 years these libs have progressed quite a bit.

Most likely the hard part will actually be getting it into the game, and playing nice with the existing GUI code, i.e. GUI1 tooltips and all that. It seems reasonable to experiment and see how hard that actually is.

Edit: It's also not clear that GUI2 should be replaced with Qt on any concrete timescale or at all. GUI2 mostly works quite well in the dialogs that use it. Qt can just be used in the cases where GUI2 is unsuitable.

[lipk]

This is not the proposal.
I compared SDL's and Qt's portability to argue that adding Qt to the dependencies is not reducing Wesnoth's portability much.

Ah, sorry, I misunderstood then. I don't think I've ever seen an application mixing Qt and SDL, can you link an example? Event handling could be rather tricky; to determine whether SDL or Qt should handle a certain event.

[Xudo]

QT allows user to define window layout using xml document structure. It is also possible to load and process custom layout at runtime.
I think it should be possible to expose wesnoth functions as QT widgets. It would be very cool to create custom theme using those widgets and QT xml markup.

UPD: Any partial replacement will make things worster. Need of support of three GUI frameworks is a pain in ass. I have faced this problem now on my regular work. In my case it is Winforms, WPF and tons of legacy code.

[Sapient]

For what it's worth, I'm a big believer in incremental improvements over massive overhauls. That's what I began when I started tinkering with Wesnoth's original GUI code and replacing it slowly with compatible, extensible object oriented code. Whenever I needed a new dialog or a feature that wasn't possible or convenient, I extended the paradigm further to enable handling that use case. You can see the result of that work and where I left off on it with the construct_dialog class, among other files. The groundwork for making it more themable was there, but that was a huge area left undone. Then what happened next was an abandonment of those incremental improvements in favor of a massive overhaul. To his credit, the total gui overhaul acheived a lot and went better than I expected. But still we are left with a bit of both, right? This next proposal seems like a bad idea on two counts: first, abandoning incremental improvements in favor of massive overhaul (again); second, giving up a cool programmer's sandbox in favor of another dependency. As a coder, coding is far more fun to me than gaming. Tinkering with the unique GUI for a well known game like BfW was an honor and a pleasure. Discarding all that in favor of Qt, even if it works, seems like a bit of a shame. Instead why not look to Qt for inspiration? Well, that's just my opinion. I realize my suggestions may not be practical if the interest isn't there.

[iceiceice]

• GUI1 was not really abandoned, it is still the primary gui of the game and has been since the beginning afaict. It will continue this way for a long time. I'm much less interested in competing grand visions (which will probably never fully become a reality) than I am in new features, and a solid foundation for future development. Keep in mind, the only reason we have two GUIs now is that the GUI2 project has not been completed. That doesn't mean though that we should abandon GUI2 and try to somehow go back to GUI1... there are many good reasons why something like GUI2 was/is necessary.
• On "incremental change" vs. "massive overhaul"... this is not really how I think about software development. To me the main thing is to take your task and break it up into the simplest and most achievable steps possible, and have the discipline to solve these in a direct manner, generating appropriate tests / docs along the way. This often results in incremental change, but you have to think outside the box sometimes. Sometimes you need to realize that the best thing is to back up and try a different route. Wesnoth does not exist in isolation -- platforms constantly change, libraries change, the language changes even. And Wesnoth adds new dependencies in response, sometimes for necessity, sometimes for convenience. For instance we have increased our boost dependencies and our sdl dependencies recently, and we no longer rely on libintl although we used to. Dependencies are not "bad" or "good", they should be added when it is necessary to fix bugs, or convenient to add features or reduce maintenance difficulties, as determined by maintainers, unless it has a significant negative impact on portability.
  The premise behind adding Qt is
  • that it will be easier to figure out how to integrate Qt and begin using its widgets, layout algorithm, and other perks, than it will be to bring GUI2 (or GUI1) to an equivalent or similar state, or even just a state adequate to support all the features we want to develop,
  • that it will ultimately have fewer bugs, and that it will be easier to maintain it all in the long run,
  • that it won't significantly hinder portability or be incompatible with other things we want to add.
  If you don't think that's true you could certainly make the case, but I don't think arguing "in general" against change / new dependencies makes that much sense. From a practical point of view fabi has already made rapid progress in integrating Qt.
• Qt can pay dividends in other ways as well. Qt appears to carry with it a ton of desktop integration code, the non-qt analogues of which we *really* don't want to maintain. For every platform that wesnoth runs on, wesnoth needs to have code for clipboards, desktop notifications, etc. to fully support all the functionality. Here's some examples:
  
  https://github.com/wesnoth/wesnoth/blob ... pboard.cpp
  https://github.com/wesnoth/wesnoth/blob ... cation.cpp
  https://github.com/wesnoth/wesnoth/blob ... cation.cpp
  
  This code is not "fun programmer sandbox", it's pretty much just hideous API, all boiler-plate nonsense, all guarded by obscure preprocessor symbols. All the people who originally wrote this stuff are gone, and when it breaks, as it has for OS X already, it will just stop working. When Ubuntu releases "Wayland" their replacement for X11, all the clipboard stuff for wesnoth will be broken on Ubuntu unless someone makes a new file like this to support it. Edit: Correction, Canonical Ltd. is developing "Mir" not "Wayland", and actually these probably will be compatible with X11 clipboard... but I think the point remains anyways.
  
  Qt however apparently supports things like drag and drop text, not only between textboxes in your application, but also between your application and another application. It appears to support this automatically on any platform where it is available, and we don't have to do anything.
  
  If we successfully switch to Qt then instead of getting feature requests "I want to be able to drag select text from the chatbox", all the GUI will just work like a normal application, and we won't have to do any more work to support crap like this. There are *many many* examples of standard UI features like this that we don't have. I don't look at that code as fun at all, I would much rather be adding new features to the game, or developing AI, than fussing with widget implementation details. And based on the commit history in the last year, it looks like most of the active developers feel similarly.

[ancestral]

I am excited for this, and I applaud fabi for the progress made thus far. Keep up the excellent work!

[Sapient]

I'm im complete agreement w.r.t. desktop integration e.g. clipboards. Sorry if I implied otherwise. I'm not opposed to dependencies when they make sense. I was talking about having our own themable widget framework. That shouldn't be outside the realm of feasibility. Right?

(also, sorry if my rude blurting of an opinion was disrespectful of fabi's efforts. I'm quite possibly wrong in my opinion, as I am slowly being persuaded)

[iceiceice]

That shouldn't be outside the realm of feasibility. Right?

I don't think it's infeasible but it's clearly not easy. It's possible that it will be easier with Qt. I view the whole thing still as an experiment, it could still fail for reasons we haven't realized yet. I'm a big fan of making experimental branches just to try things out, you can sometimes learn quite a bit this way.

---

For who is interested, I had some difficulties to overcome to build with Qt when using linux mint Qiana, stemming from that Qiana is based off of Ubuntu Trusty Tahr (14.04) which only has Qt 5.2.1, while fabi used Qt v 5.3 available only in Utopic Unicorn. I was able to install 5.3 outside of the package manager, it's pretty standard but I put the instructions here anyways:

• Remove all qt related packages from the package manager. This might not be necessary but it makes it less confusing, you won't have dynamic link errors and pkg-config won't get confused. Essentially I did

  Code: Select all

  sudo apt-get remove qt*
  sudo apt-get remove libqt*
  

  If you are using a KDE desktop this isn't going to work, you'll have to skip this step or deal with it some other way.
  If you use using the cinnamon (gnome) desktop this is probably no big deal.
• Go to Qt project website, click download, download the online installer. https://www.qt.io/download-open-source/
  Run the installer as root, so that it will allow you to install to /opt/ instead of to your home directory.

  Code: Select all

  sudo ./qt-opensource-linux-x64-1.6.0-7-online.run

  /opt/ should be the default install location.
  Select to install 5.3 instead of 5.4. (5.4 has library dependencies that Qiana does not carry.)
  The installer will build a proper repository and manage it for you -- in /opt/Qt/ you can find "MaintenanceTool", a gui for managing your installation.
• Register the new libs with ldconfig:

  Code: Select all

  $ sudo ldconfig -n /opt/Qt/5.3/gcc_64/lib

• I also added the following to my bashrc:

  Code: Select all

  #Add LD_LIBRARY_PATH to ensure we link with libs needed by Qt core
  export LD_LIBRARY_PATH=/opt/Qt/5.3/gcc_64/lib
  

  If your LD_LIBRARY_PATH already has contents (run env at your prompt to see) then you probably want

  Code: Select all

  export LD_LIBRARY_PATH=/opt/Qt/5.3/gcc_64/lib:$LD_LIBRARY_PATH

  instead above.
• I build wesnoth using the following script (`build_qt.sh` for me)

  Code: Select all

  #!/bin/bash
  rm .scons-option-cache
  
  #Add QT library path to help it link against these
  LIBRARY_PATH=/opt/Qt/5.3/gcc_64/lib
  
  #Add QT pkg config dir (installed to /opt/)
  PKG_CONFIG_PATH=/opt/Qt/5.3/gcc_64/lib/pkgconfig/:$PKG_CONFIG_PATH
  
  scons wesnoth wesnothd test build=release extra_flags_release="-O0" cxxtool=g++ ccache=yes jobs=3 --config=force
  

  Similar advice applies to LIBRARY_PATH as LD_LIBRARY_PATH.

I cannot build with clang, only gcc, I'm not completely sure why. Possibly it could be solved by building qt from source...