v0.5.1

And here comes the macOS platform :) All backends, all examples, all companion libs - everything's here! As expected using Objective-C made it a lot easier to implement, but systems programming is always special on Apple platforms so the design phase thankfully spiced up the whole process with a few delicious headaches.

More specifically, you will find in the example/helpers folder a new appkit.m source file: it holds example code for a minimal macOS application, the construct macOS expects graphical programs to rely on in order to integrate properly in their desktop ecosystem. This is for instance what controls the bar displayed on top of the screen and the menu appearing when you click the app's icon in the dock. Previously I created the application with the window, inside Globox. However I realized coming back to this problem an application could very well control several windows. Because of that, I decided to move it out of the library and have it part of the examples, which allows you to create multiple windows for a single application using Globox.

This was a hard decision to take, because as I have detailed in the past AppKit basically requires that you let it steal the main thread in order for it to spin its own secret loops and logic - the result of a bad design decision said to be dating back to the days of NeXT. For us, this means a program ported to work on macOS has to start an application in the main and create a new thread to run its code aside.
As you can tell though, the examples were barely touched (it's the goal after all). This is because we can simply redefine the actual main of our program to bear another name and call it from a secondary thread created in the AppKit-specific example code! It works perfectly, and we don't even have to change how our code is organized for it to work on macOS. Cool right?

This iteration is clearly a lot cleaner than the previous ones in every possible way. I only had to use the Objective-C runtime once in the cursoryx companion library because Apple makes certain system cursors private. This can be disabled when compiling cursoryx though, in case you want something free of any undocumented API use - in which case some cursors will simply be replaced by fallbacks. I'd say using these private cursors is pretty safe however, since this is what Apple does in WebCore/WebKit/Safari to support CSS3 cursors...

Vulkan works using MoltenVK and the OpenGL backend currently supports OpenGL ES through ANGLE. I had originally planned to use MGL which implements desktop OpenGL 4 using Metal, but reading the code I noticed it still used Apple's old OpenGL API to get some info, which is a blocker for me. In theory OpenGL-on-Zink-on-Vulkan-on-MoltenVK-on-Metal should be possible, but the code to do so through EGL does not exist yet in Mesa, although some people have been working on enabling this recently. Maybe one day :) Of course all contexts support background blur.

Because I do not own any Apple hardware however (this entire thing was developed on a hackintosh) I am not able to test it as thoroughly as I'd like, but it should support retina screens just fine (I will make sure it does when I can access a true mac again, hopefully in a few weeks). One thing I made sure to test however is monitor detection using dpishit, and it seems to be working fine.

Now I have to say there is still room for improvement on this platform, especially when it comes to maximization, which does not support rendering the window's content during the animation. I have no idea how to do this, so it will have to be fixed later. Another important missing feature is proper object destruction, which I skipped because it can be fixed using Objectice-C autorelease pools. I'm very sorry this is not done properly but I had to work hard to make this all happen and I'm getting a bit tired. We're clearly 99.9% here though, so le'ts celebrate (and maybe take a break this time) before moving on to our next target: Windows.

Just like the macOS backend was a nice incentive to learn Objective-C, I will take that opportunity to come back to C++ and perfect my knowledge of its modern features in the process. Previous versions of Globox used 100% C99 for the Windows part, but I plan on using DirectComposition to provide high-quality background blur this time, and this requires using C++.

N.B.: The archives do not contain natively compiled macos binaries, only cross-compiled ones since this is easier for now. If cross-compiling becomes hard or impossible I will switch to providing native binaries of course.