v0.5.2
Pre-releaseI failed at taking a break... which means it's already time for another alpha release! This time for Windows, and again with everything ready, backends, examples and companion libs. Development went rather smoothly, although my initial plan to support Acrylic blur using Microsoft's private APIs wasn't quite successful.
As I described in the previous release notes, I originally intended to implement the new Windows platforms for Globox and its companion libs in C++, mainly to make it easier to replicate Acrylic blur with DirectComposition and Direct2D. Unfortunately, MinGW does not seem to provide up-to-date headers for these APIs, which means we'd have to patch the existing ones... Not quite an acceptable solution in my opinion. In the end I took the difficult decision to not implement background blur on Windows, as the only other way to achieve this would be to rely on the older compositing tricks demonstrated in the previous versions of Globox, which simply do not give a qualitative enough result.
It's really sad since Globox proudly advertised support for cross-platform blur in its previous iterations, but I think it is the right decision. Writing the earlier versions of this library has taught me we can't always succeed in the fight for portability when proprietary platforms are involved. For this new version of Globox, I decided to only support MinGW and focus more on maintainability, and supporting Acrylic blur (not to mention using private APIs that could break at any time) is just not possible with these constraints.
In more enjoyable news, this new version of the Windows platform works much better than the previous ones! It's been rock solid even under Wine in most of my tests. Wiring everything according to the new multi-threaded design of Globox was not a very pleasant task, but in the end I think we got a pretty good result. This is quite a relief, since the Win32 API was clearly not built to handle parallel execution and there are a million ways to shoot yourself in the foot trying to do that, but being paranoid about synchronization and carrying out extensive tests paid off in this case. The MSDN documentation is actually quite helpful about it, and does give good tips to avoid making everything explode when sharing Win32 objects.
Some changes to the interactive move and resize Globox feature had to be made in order to guarantee a consistent behavior across platforms, since Windows is more restrictive than others on that matter. There are more minor fixes to X11 and AppKit as well in this release but nothing important, mostly some cleanup made along the way.
This time I also spent a few hours to try to fix the Windows console output issues that have always plagued the complex examples. Keyboard input is usually printed glyph-by-glyph in these, thanks to our Willis companion library, with complete composition support. On Windows however, the output has always been invalid, but my code seemed to work fine as the character codes it returns are right. Well it turns out this is just another unfortunate consequence of legacy support: Microsoft's printf functions do handle UTF-8 output, but exclusively through wide-character strings, which is not documented anywhere and has been driving people crazy for around 20 years now if the various forum posts I found are to be believed. In the end I made the complex examples print a warning about this when compiled for Windows, since copying bytes in wide characters one-by-one just to fix that would not make a lot of sense.
Another quirk I found when testing multi-monitor support is we can't get the physical size of secondary monitors. Again there is simply nothing we can do about it, solutions exist but require privileges or straight-up reading the registry, hoping for the best...
I am also sorry to report some parts of my CI system for macOS broke, and I'm afraid it will slowly but surely get worse with time. I can't build my cross-compiling toolchain from Alpine Linux anymore, and with Alice stepping down as a package maintainer for this distro the future is not bright. I was also not able to create a proper setup for Windows/Vulkan because the required packages are not available. As a result, this release's Windows binaries were generated from Windows and its AppKit binaries from my Hackintosh.
To end on a positive note, I can confirm Globox fullscreen windows benefit from exclusive fullscreen promotion! This works for the Vulkan and OpenGL backends: Microsoft made some changes some time ago in their compositor to detect borderless fullscreen windows and automatically promote them to exclusive fullscreen when nothing else is showing up on top. You can tell it happens in our case because the window suddenly looses its transparency and you can no longer see the desktop through it. Pretty cool!
I think this is it, I have some stuff planned for the next month and a half so taking a break is not an option this time, but I will be back with our last desktop platform: Wayland! Until then have a nice summer you all ;)