For those that don’t know GNUstep is a project that started many years ago to help bring Objective-C to the masses using operating systems other than
Mac OS X macOS. Actually, Objective-C already existed on any platform that had access to the GCC compiler suite but what GNUstep sought to do was bring the primary frameworks (libraries) that were being used on macOS to make porting Mac applications to other platforms a lot easier. In particular we’re talking about the Foundation and AppKit libraries.
For the most part they’ve nailed it on the head for simple applications and the Foundation library seems rock solid and fairly up-to-date with the Apple versions. In fact the Foundation library seems to be up-to-date with at least macOS 10.9 and some of 10.10.
That said, there are a couple of places where people, including me, are having serious problems with GNUstep. I have to add at this point that these are constructive criticisms! The GNUstep folks had a definite goal in mind when they started and I have to say that they hit the nail on the head with this. Also, like many open source projects, it’s an all volunteer army where people have day jobs and others simply lose interest for other projects. In fact, the introduction of Swift has definitely contributed to that last point – many people have given up on Objective-C and jumped on the Swift bandwagon.
1. They Keep Breaking It
This mainly applies to the AppKit libraries when trying to use Objective-C 2.0 features such as the non-fragile ABI and ARC. If you want to build your Objective-C 2.0 projects with the non-fragile ABI then you’re not going to be able to use the AppKit libraries. Otherwise you’re applications will crash with a notice about mismatched ABIs. The solution is to build without non-fragile ABI support. This is not always desirable.
2. Strict Adherence to macOS Paradigms
Apple’s operating systems (macOS, iOS, watchOS, tvOS, etc.) all have this paradigm where basically everything is a directory. Especially Frameworks and GUI Applications. GNUstep tries its best to replicate this paradigm on other platforms but the truth is that it just isn’t necessary and adds a huge amount of complexity to the build process and the resulting product. The paradigm works very well indeed on Apple’s operating systems because there is support for the paradigm built right into the operating systems. But on other operating systems such as Windows and Linux this paradigm doesn’t work so good. In my opinion, and I’m not alone, it would be best to simply follow the best practices of those other platforms rather than trying to hammer a square peg into a round hole. This applies to packaging too. The default package manager for each platform should be used. It’s less confusing for users of those platforms.
2.1. This Applies to GUI Applications Too
The GNUstep GUI applications ALL look like they were all written about 30 years ago. They use concepts and HID guidelines that harken back to the NeXT operating system from whence everything is modeled from. Even Apple has dropped most if not all of these old HID paradigms in favor of ones that are more modern and practical. I mean, honestly, who has main menus that just hover somewhere detached from the main window of the application. Really?
Yeah, okay, I know – GNUstep has this neat pluggable theme system and can be customized but 1) this is highly problematic (see point #1 above) and 2) it is not well documented – if at all. And if it is documented you can’t find it unless you spend years scouring the web and happen to stumble across it like I did when I found this some FOUR years after it was first posted. (scroll all the way to the end of the post to “Step 15: Making it Look like a Linux Application“)
Everything should be moved to CMake. ’nuff said.
There is no support in GNUstep for packaging your applications for distribution to system that don’t already have the GNUstep libraries on them. I’ve seen ONE very outdated partial document describing one way to do it but that’s it.
How to Fix This
In an upcoming post that I’ll be sure to link to this one I’ll outline some steps for addressing these issues. At least a couple of them I have already started work on: https://github.com/GalenRhodes/Rubicon