Azoth started life because my couple of decades at Apple has come to an end, and I prefer writing in Objective C / AppKit than in Swift / SwiftUI. The writing is clearly on the wall for the direction Apple is taking (in terms of support and resource allocation) so although I don't believe that AppKit will go away in the forseeable future, I also don't expect it to be maintained much going forwards.
I also (now that I'm no longer working there) interested in a cross-platform UI, and although GNUstep is a wonderful project, it comes with a lot of baggage with filesystem layout and installation is ... complex.
So, looking around, SDL3 with its hardware-accelerated rendering was just about to announce a stable API, and since that takes care of a lot of the cross-platform issues, "all" I had to do was write something that implemented the AppKit classes, and life would be good. A quick test that Microsoft still supplied clang with objc, and that it was possible to get the GNUstep Foundation (so, just the runtime and non-UI framework) up and running with SDL (spoller, it works!) and we were off to the races.
AppKit is huge. I'm not going to try and implement it all, or even a significant fraction of it. I've never used most of it in over 2 decades of working at Apple, so the goal here is to hit the highlights. I want:
All of these together add up to quite a lot of work so it's not a minor undertaking but hopefully it will pay off in the end :)
There aren't many places outside of Apple where Objective C (hereon, ObjC) is used. This is quite a shame, because ObjC isn't an Apple technology, although they were early adopters. It's an awesome language which people tend to gloss over, apparently because of the bracket syntax... ObjC makes life pretty easy for programming in...
All this for some syntax that is, admittedly, a little different, method calls being brackets by [...]. The reason for the difference is in that first bullet above though, it's a pure superset of C - so nothing it does can ever be confused with how C does it. If there's any possibility of confusion, you lose the C interoperability because the compiler won't know which type of code to generate. So you end up with a different syntax... Worth it, IMHO.
Which is a long way to say that Azoth is written in ObjC. The goal is to keep things as similar as possible to AppKit without going overboard in trying to support all the baggage that AppKit has accumulated over the years. It'll be interesting to see how well we manage to do that.
There have been a couple of implementations of AppKit outside of Apple over the years - GNUstep is the one that's kept going the longest, and is still an ongoing project today. Another one is Cocotron which has sadly passed into abandonware.
Azoth is not like these - there's no attempt to keep the NS namespace (we use the NS prefix in all the Foundation classes, because we get Foundation "for free" from GNUstep or (on the Mac) ... Foundation [grin]) but all the Azoth classes use the AZ prefix, so for example instead of NSTableView, Azoth provides AZTableView etc. etc.
The guideline for Azoth is to be as similar as possible to AppKit without making it burdonsome to support something off the beaten track. So we end up with something similar, but unashamedly different. You might be able to port an application from AppKit to Azoth by changing any UI classes from NS... to AZ... ... but you might not, either.
Sometimes decisions have been made to simplify, so for example AZTableView and AZOutlineView only provide "view-style" behaviour, not the older "cell-style". Computers are very fast at heavy-computational-load tasks like this!
Sometimes the underlying cross-platform nature of SDL gets in the way of an AppKit paradigm, so instead of grabbing the mouse and using a local loop for processing a mouse-drag, you have to use the "three method" technique (-mouseDown, -mouseDragged, -mouseUp). Both techniques are valid in AppKit, but Azoth only supports the 3-method approach.
etc. There are differences. Mostly it's the same.
Azoth has taken some of its implementation from Cocotron, or other BSD/MIT-licensed open-source libraries on the net. Where this has happened, there are files in the Documentation/ folder in the repository which detail the sources, and I would like to personally thank all those who have provided their work for people like myself to build on.
Using ObjC makes it easier to develop on, but it comes with the cost of requiring runtime support. As it stands, it seems like Windows support should "just work", for some defintion of "just work" which involves grubbing around using CMake. Linux support ought to be possible too (since GNUstep is the main dependency, and that works under Linux).
The main platform is the Mac - simply because that's what I use :) I do want to make sure it works across platforms, and I have verified that a minimal SDL3 + ObjC program can be written. It might just be HelloWorld, but actually getting that far means a lot has already gone right.
So this is a bit of a work-in-progress, and I'll update the content once I have more to say about it
Despite what it might sound like, Azoth is in fact not associated with devil-worship at all...
One of my other main frameowrks over the years was an object-relational database wrapper around SQLite. I've been using this since before CoreData was around, and it was called QuickSilver. QuickSilver is an archaic name for Mercury, but "Mercury" was already taken on the Mac, so looking it up there was (yet another) archaic name for Mercury - Azoth. And so Azoth the project was born.
The domain was taken, of course, but what we have suffices.