Patch:qt-4.6-4.7-compatibility.patch (Source code patch, 6.5 KiB)SHA1 checksum: e9e800c98bdb79c234d536277bfb5d3ea9014a89You only need to apply this patch if you are building version 0.2.0 from source using Qt 4.6.x or 4.7.x. Run qmake -v in the console to see the Qt version in use.

New in this version

One year and nearly eight months have passed since the last release, version 0.1.4. There was very little activity for most of the time until July this very year, although the primary release goals had already been long established.

The new built-in palette and color range editors allow creating and modifying these items for the game’s recoloring engine with ease, as well as generating WML definitions for your use in add-on production and testing. Various user interface improvements and additions, such as a Recent Files section and a Reload action, allow for a smoother workflow. The redesigned main window now supports scrolling large and zoomed-in images, as well as dragging any of the previews to other applications accepting graphic drops, such as the GIMP.

This version also sees the addition of menu options to change the preview background color, cleaner file output notifications, an enhanced Windows build process with embedded version and icon attributes, and a simple make install target for Linux/X11 users building from source. The included documentation has been improved in this release as well.

Known issues

Some of the known issues with this release are mentioned in the BUGS file included in the source code tarball; other issues have been fixed after the release, in the master branch in the public Git repository.

The unmodified 0.2.0 source code distribution will not build using Qt 4.6 or 4.7 without the patch provided in the Downloads section above. This issue was—rather unfortunately—discovered after the release was tagged. The fix has been committed to Git already.

Zooming in requires extremely large amounts of CPU time and memory, especially for images larger than 72x72 pixels at zoom levels greater than 200%. It’s advised that you avoid zooming in unless you have at least 2 GiB of RAM available.

Zooming does not preserve the current viewport, indiscriminately recentering it instead.

The preview background color choice is not persistent across re-runs. This has been solved in Git already.

The dialog shown by the Add from List option in the Palette Editor may have the help text cut off depending on your display and font configuration.

Dragging previews is not always possible on Linux/X11, depending on the Qt 4 style engine in use. A workaround has been implemented for the Oxygen style (KDE workspace default), but other styles that allow dragging windows from empty areas may ‘steal’ Wesnoth RCX’s events.

Dragging previews to Windows Paint does not currently work, presumably because the application expects to get access to a file on disk. Since Wesnoth RCX does not store the recolored image on disk until the user requests it, this problem might be impossible to fix.

The Windows build might occasionally crash during the initial file open dialog, apparently whenever a directory takes too long to display. This does not seem to happen later during execution.

The Windows build might display occasional minor glitches with mouse-over decorations on buttons and radio/checkboxes when running on Windows XP with styles supporting them (e.g the default Luna style).

The Add from List button in the Palette Editor remains enabled at times when it cannot do anything useful (e.g. when there are no palettes to select and edit). This has been solved in Git already.

As usual, you can also provide other kinds of feedback through those two aforementioned channels. It would be nice to hear from you if you use this software, regardless of whether you liked it or not — any feedback is appreciated here.

Finally

One problem in terms of development and testing is that I do not currently own a Mac machine, nor do I really intend to. This means I have to rely on certain assumptions and avoid doing anything too crazy that is not guaranteed to work on all platforms or—in particular—widget style engines. So far this appears to have worked fine, thanks to Qt’s cross-platform design.

The Windows (Win32) build has been tested much better in that regard, since my current development machine also functions as a decent VirtualBox VM host. I have gone to rather great lengths this time to improve the build by adding some embedded information to blend better with the environment, and including the Qt library in the wesnoth-rcx.exe executable itself, thus removing the need for two DLLs in the distribution.

Testing on Windows and Mac OS X feels really important to me, given my target audience; most artists seem to prefer these mostly hassle-free operating systems, and I fully respect that choice. My goal is to reach as many artists as possible with a useful and powerful tool that does not get in the way of the creative process, unlike the Wesnoth game proper, so it’s important to ensure a minimum quality level for each release that is consistent across the three main supported platforms.

I have done a lot of work coding and testing this release on Linux (Debian wheezy), Windows XP, and Windows 7, and I hope there aren’t any showstoppers left in this version. However, as you can see above, there is still quite a lot left to do in terms of polishing. Depending on feedback, a new 0.2.1 release might be published in the upcoming weeks. However, many of the remaining bugs require more meticulous inspection and extensive design changes; those will not happen until 0.3.0.