v0.5.3

And it's a wrap! Globox now supports Wayland, again with all the companion libraries ready and all backends implemented. Development went rather smoothly, although some ideas collected along the way to improve our use of the protocol cost us a few deep dives into the display system's design. In the end it's for the better, since these efforts got us an extra clean API for this platform, with few structure-specific getters.

I didn't talk much about this in the past but with this iteration of Globox I tried to make it possible to write companion libraries without having to get a lot of specific low-level structures from Globox. At first this seems unavoidable, and to be honest coming up with a good design for a windowing library with a strong portability focus is already so hard I wouldn't blame anyone for not trying to. But it was the third time I started writing such a library from scratch, so I had some experience and a few ideas to try to make it possible, and quickly this became one of the many small reasons that finally convinced me a second re-write would be interesting. If you take a look at one of the complex examples in the repo, you will notice the amount of initialization data for each companion library was indeed reduced, and quite dramatically since their AppKit and Win32 backends simply do not require anything. Only good-old (but mostly old) X11 has to be fed some basic structures, kept to a minimum. For the new Wayland backends however, we do not usually supply structures, but functions!

Indeed, the Wayland versions of our companion libraries can't get all the data they need by themselves, but luckily the Wayland protocol makes it possible to negotiate protocols and surface features. Using the functions provided by Globox from companion libraries, it is possible to register callbacks to tap into these exchanges and get all the data we need. This is huge, because without such a system, implementing new companion libraries with Wayland support would require making some additions to Globox as well, in the lines of negotiating support for a new protocol internally and providing new getters for the specific structures it introduces. Quite underwhelming. With this new system, everything's easier Wayland-side. I did have to introduce a new Globox API call however, because I did not foresee how Globox feature negotiation would play with our Wayland registration pass-through. It's a bit sad but really not a big deal, you just have to call globox_window_confirm after globox_window_create now, and all the companion libraries initialization (and interaction with internal stuff in general) has to be done in between them instead of before globox_window_start. The feature config callback is also only called from globox_window_confirm now.

I also made some changes to our build system so the distributed binaries are cleaner: only public API symbols are marked as general for the ELF and PE formats now (MACH-O doesn't need this). To achieve that we perform a first linking step before archiving objects: the goal here is to resolve symbols between objects that will end up in the same static library unit before making the remaining ones local, with the exception of public API symbols that should stay accessible to users of the library and are kept general. This should help prevent name clashes that could result from the library's static-but-modular architecture. If you are wondering how it is even possible to implement such a trick at this stage, very good question: the answer is it was all planned from the beginning :)

I was able to test triple-monitor Wayland DPIshit reports by plugging all my stone-age tech together, and I'm happy to report it works wonderfully - X11 and AppKit were tested on two monitors only, and as you know Win32 doesn't support multi-monitor EDID info retrieval... The other companion libraries work fine as well, some more work will be required to have all backends behave exactly in the same way, but that shouldn't be a lot of work.

There's still a lot to improve in Globox (starting with fixing bugs) but at last we have all platforms, all backends and all features implemented for the first time. The architecture is finally acceptable, the library is more modular than ever, and we didn't use hacks. While we are still clearly in alpha for now, it's time for this version to be the one in the master branch. I think it's fair to consider this third attempt as a success!

That being said, I decided to slow down on Globox from now on, and focus more on other projects. You can expect a few commits here and there since I will definitely be using Globox for these, but clearly changes won't come at the same crazy pace as before. During the past year and a half, I've been burning the midnight oil to make that new version feature-complete before 2024, haunted by this deadline that for several reasons will most likely mean the end of time-consuming personal projects for me. I'm happy we made it! But I'm also very tired as this project has become way, way too big for me to handle alone. Luckily I had thought about setting up a continuous integration system to help alleviate some of the most tedious work, but even this is barely enough now. This release took me three whole days to pull off. Three whole days of doing nothing but working on the release for 10 hours a day, polishing our build system and testing all generated binaries in as many configurations as possible. For now we only produce alpha releases, but I fear the day we will have to distribute 1.0, hopefully other people will have joined me by then. Until this time, I will try to make small fixes as I go, squashing bugs one by one (I will be opening issues for those in the coming weeks).

Thank you all for your support, it means a lot ❤️