Wespal 0.4.0

After a very long hiatus, I finally got around to dusting off an old tool I wrote yeaaaars ago for previewing recoloured Wesnoth assets. Over the past month, I ported it from Qt 4 to Qt 6 (and C++17), cleaned it up, and hopefully properly ensured that this time around everything works 100% fine on macOS — except for the lack of app signing, at least.

Wespal (formerly Wesnoth RCX) version 0.4.0 is out now!

I actually have quite a lot of things to say about this release.

Changes at a glance

• New icon.
• Rebranded to Wespal.
• Building from source now requires Qt 6.4 or later, CMake 3.21.1 or later, GCC 7 or later / Clang 5 or later / another C++17-compatible compiler.
• WebP images are now supported on Windows and macOS builds, and also on other platforms if the relevant Qt ImageFormats plugin is installed.
• GIMP XCF images are now supported on all platforms without depending on the KDE Frameworks runtime.
• There is a new startup workflow where the app no longer forces you to select an image, instead showing you a page where you can choose what to do next, including selecting a recently opened image to open.
• The Recent Files history limit is now 8 instead of 4.
• It is now possible to close the active file without quitting the app.
• Everywhere that a colour range or colour palette name is displayed, there will be an icon with its colour to make it easier to recognise — especially useful for custom ranges and palettes.
• Various changes to make the app feel more native on macOS.
• The Colour Range Editor now has a “From List” option to allow copying colour values straight from WML.

Rebrand

The biggest change from version 0.3.0 is obviously the branding. Somehow, despite the app very obviously revolving around colour palettes since its very inception, it took me 14 years to come up with Wespal.

Originally, I codenamed the app Morning Star because I somehow couldn’t come up with a proper name for it. By version 0.1.1, I settled on Wesnoth RCX as a preliminary production name, but intentionally kept all internal identifiers based on the codename since I felt that was still too awkward of a name for it. Later releases kept the name though, since I decided to prioritise work on Wesnoth proper — as well as my add-ons — over Morning Star in general, only doing occasional bug fixes and quality-of-life features. I just didn’t really spend any additional effort on the name even though I utterly hated it. 🤮 What kind of name is “RCX” anyway?

My biggest hope with this change is that people (and myself, really) will no longer get confused whenever they spot “Wesnoth RCX” or wesnoth-rcx on listings.

One annoying side effect, however, is that Wesnoth RCX version 0.3 and Wespal 0.4 use completely different configuration files/registry keys. I ran into a lot of unexpected technical difficulties trying to implement a migration mechanism, so I decided it would be simpler for me to just not have one at all given its tiny userbase. Sorry about that. 😓

Tech

Very importantly, Wespal marks a massive leap in library versions, from Qt 5 to Qt 6.4+. I did temporarily consider requiring only Qt 5.15 instead, but I feel Qt 6 has been around long enough for it to be something I can rely on so that things such as high DPI screen and Wayland support can be complete non-concerns for the foreseeable future.

In particular, the newest Debian stable distribution (Bookworm) — includes Qt 6.4, and the previous stable carries it in its backport repository.

As part of the porting process, I decided to drop the qmake project file as it feels extremely inflexible and I wanted to be able to properly support Windows, macOS, and Linux platforms together, including providing built-in support for XCF via bundling part of KImageFormats with Wespal. The CMake version requirement is a bit steep (3.21.1) but again, Debian stable carries a newer version that is also available in oldstable’s backports.

(In the worst case, someone who can’t build Wespal on Linux against their distribution’s Qt 6/CMake stack, either because it’s unavailable or too old, can potentially run the Windows build using Wine.)

macOS support

This is the first time I can provide macOS support myself without relying on other people to build the sources or submit patches. Because these days my Macbook is my main development system, I’ve extensively tested Wespal on it and made quite a number of changes to make its fit better in.

What I can’t provide right now, however, is app signing. Although surprisingly, independent macOS app signing is still far cheaper than Windows app signing, 99 USD a year is not something I can quite justify right now for a project that has about one user including myself. I would be willing to consider it at some point in the future if Wespal spikes in popularity somehow, but for the time being, the unsigned app will have to do.

From the macOS-specific instructions on GitHub:

To add an exception for the app, you need to use Finder to browse to the folder where Wespal is installed, and attempt to open it twice using right-click + Open. The second time you do this, there will be an Open button underneath the warning, which you can then click on to allow Wespal to launch.

Note:

I am aware that I was previously asked to make it so closing Wespal’s main window on macOS doesn’t actually quit the app. I am still on the fence about this since I feel that Wespal not being a full-fledged image editor, as well as not having the ability to open multiple files (yet) makes it a bit awkward as a traditional app. But it is something I am still considering.

Closing thoughts

For version 0.5.0 and now I’ve tidied up and even simplified a lot of the existing code, I would like to overhaul the main UI to allow for alternative display modes such as onion skin and sliding for comparing the “before” and “after” more easily. I also want to implement the ability to open multiple images in tabs, or even sets of images in a single tab for e.g. previewing recoloured unit animations.

Regarding support for other Wesnoth Image Path Functions: while this sounds vaguely like a good idea, the fact is that many of these functions rely on Wesnoth’s binary path search mechanism, which is very difficult to replicate outside of its intended context:

• For an external app to understand Wesnoth IPFs like ~BLIT(), it would need to have knowledge of the search paths intended for use with the function. This is not something you can extract from an image file alone, so you would need a complete mechanism to define an add-on in the app.
• A mechanism like this would either need to require the user to reinvent the wheel and inform Wespal of the existence of an add-on in a Wespal-specific way, or incorporate Wesnoth Markup Language support.
• The Wesnoth Markup Language code in Wesnoth suffers from a very nasty chronic case of tight coupling, pulling in all sorts of other components in order to provide its services. It’s very much not usable in C++ apps outside of Wesnoth without some extensive code wrangling.

In addition to the above, the complexity of implementing transforms like ~ROTATE(), ~SCALE(), ~CROP(), ~MASK() and the like makes it waaaay more reasonable to just have people use an actual image editor like the GIMP, Krita, or Adobe’s GenAI siphon flagship overpriced pile of trash.

I do intend to keep a close eye on development of Wesnoth 1.20 and later in the event that it ends up receiving native support for stuff like spritesheets, as this would definitely be something that would necessitate the use of a more specialised application to preview assets, especially combined with the team colouring system.

For the time being though, Wespal 0.4.0 is out, my itch is scratched, and I can resume work on other things. I’ll keep you all posted on any future progress on my 0.5.0 wishlist features. 💜