My only experience with GNUStep is that 10 years ago, as a student, I needed to port a random CLI Cocoa app (that a different student wrote to learn Cocoa) to GNUStep.
There was a weird bug that took me forever to debug… and in the end, it was caused by some horrible bug in some map structure (NSDictionary? I think?) where a NSString unicode key did not map to the same value every time. Quite basic stuff. (It worked fine on Mac.)
As a student I didn’t really know how to report bugs, so I didn’t; I just wondered how did nobody catch it until now; but I just thought that probably nobody really uses GNUStep so that’s why.
It’s just anecdotal and I don’t really have access to the code anymore so I cannot tell you the details. (the original code was far from perfect too, maybe it was some unicode weirdness.)
You made think about digging old hard drives and trying to figure out where are all the files from 2013 again… I think I could find the actual underlying issue much faster now.
My personal experience mirrors yours. I remember when Swift announcement from Apple came that the main author of GNUStep (sorry I forgot the name) announced an open source impl the same day. My thoughts back then: „maybe make the last effort actually usable before jumping to the next big project“.
But I don‘t want to downplay the work and time put into this project. I would simply not use it in any project because of the number of compatibility bugs that haunts the project.
I used the project in production via Apportable’s crosscompile solution to port iOS native apps to android.
That’s concerningly bad luck, or an exaggeration. The entire Internet, hell, technology as we know it, operates on the premise that a bunch of open source code works ‘pretty well’.
Go to GitHub and file a reproducible issue. In this case it might be “here’s a shell loop that runs a test 10 times. On my system it fails about 40 perfect of the time”
Can you list some references to bad software you are using perhaps? Someone else who also uses open source software might be able to suggest a different tool or fix you may of not known about.
Every software will be bad software if you use it often enough to the point you step into some specific usage that developer and tester never imagine about.
The point isn't whether it is good or bad. The point is nobody use it like that thus nobody knows it would break.
The good thing about open source software in general is: if you complain and give a detailed procedure of how it happens, there is much higher chance somebody might looks into it (or yourself if you will). Closed source software in the other end: good luck, find a workaround if you hope or just stuck with it.
The keyword here is 'much higher'. It is of course not guaranteed. As a developer, if somebody already done the trouble shooting or even root cause finding for you. You are more likely to fix the bug first because it will only cost you a little time compares to other completely non-investigated error report. And that also benefit the users because they got the bug affecting them fixed earlier. This don't happen in closed source softwares.
I wonder if GNUstep is going to follow in Apple's backwards compatibility breakage or they'll try and keep existing programs working.
Free Pascal and Lazarus devs also implement a language and API originally defined by some big company in the past and in general try to implement the new stuff Delphi adds, but they also try to avoid breaking existing code. In Free Pascal this is done by using compiler directives in the source code to opt-in for the Delphi stuff whereas in Lazarus they only implement things that do not break existing code - either way you can have code that works with both Delphi and FPC since they're 90% compatible but you need to use IFDEFs for that that last 10%.
Even though i'm using Window Maker and thus GNUstep apps would feel right at home (for the most part), i haven't actually bothered to look into it because Apple has a bad history with breaking existing applications (i got an iMac in 2009 and pretty much every single Mac OS X / macOS update broke some application that previously worked fine - until macOS itself stopped supporting my iMac) and GNUstep's "we're not implementing NextStep anymore, now we're doing Cocoa" stance gives me an impression of "we're going to break your apps just like Apple does".
(of course that is one reason, another is that when i tried some programs made with it years ago there were major glitches and bugs like the text editor widget locking up the entire program - admittedly that was years ago and it probably has been fixed but it did give me a bad impression since the project was already more than a decade old by then and already in a state where barely any developers worked with/on it)
Basically, what i wonder is, if i make a Linux binary today that links only against glibc and the GNUstep libraries (including the ObjC runtime), will it work in 10 years[0] even if it uses some API that in the meanwhile Apple decided to change or it'll break? Ignoring of course breakage forced on the project from outside forces they could do nothing about (e.g. for some unfathomable reason the C ABI itself changing or everyone switching to RISC-V with all x86 CPUs blowing up at the same time and every x86 emulator out there suddenly losing both its source code and any existing binaries).
I get the impression with ObjC having a very "dynamic" nature it should be possible to do that.
[0] obviously if it works in 10 years it'll also work in 20 years since in 20 years a binary made 10 years from now will still rely on the libraries being backwards compatible - the 10 years was an example to give a sense of scale
Is backwards compat a thing on osx? The kernel ABI is not stable, I don't know how often their libc equivalent changes. Glibc doesn't make much sense in that environment.
My guess would be that your hope is doomed by the platform whatever GNUstep does.
It really depends. I managed to get a universal intel 32/64-bit app compiled on OS X 10.5 run on Catalina, which is 10.15. But it was a very unremarkable app. Just a simple NSWindow and label. Nonetheless demonstrates you can technically have some backwards compatibility.
At one point in time (say 2004), you would've been able to launch Classic environment on a PowerMac G5 and emulate 68k software in Classic, all the while enjoying OS X software natively. That should span some decades worth of Macintosh software, but of course this era is simply gone now.
Last time I played with getting a moderately complex old (Jaguar/Panther/Tiger era) Obj-C/Cocoa OS X app building on modern macOS, fixing the build-stopper errors didn't take too long but there was a mountain of deprecation warnings, despite everything seemingly working as expected.
That was a few years ago though so I wouldn't be surprised if some of those deprecations have turned to errors in the meantime.
To an extent, they've removed things like Carbon (the Classic Mac OS descended API) and 32 bit support in general, but they don't go out of their way to gratuitously break the Cocoa API or libc. But they aren't Microsoft with the whole "Win32 must never break compatibility" mantra, so randomly stuff kinda breaks between versions more though neglect than intention?
See .NET Core migration, Windows Runtime tooling, Xamarin/MAUI, UWP/WinUI 3.0,...
The folks that were responsible for that kind of backwards compatibility apparently are no longer there, replaced by younger blood without any knowledge of Windows development history.
Nowadays we even get CLI stuff instead of nice VS wizards.
Windows has a Compatibility Mode with is unmatched by any Operating System maker. I've got Windows 10 running Visual FoxPro 3.0 from 1995 and Visual Basic 5. Try that on macOS or any linux system with any application with a GUI from source or binaries.
I was referring to using GNUstep as a framework/toolkit for Linux, not macOS and the reason i asked that was exactly because macOS has issues with backwards compatibility and GNUstep has the goal of copying Cocoa - my question was, "to what extent?"
Linux is backwards compatible going back decades and glibc also largely maintains backwards compatibility as long as you are not using hidden APIs - and realistically if you stick with the common C stuff you should be fine in most systems (AFAIK outside of Linux, most Unix systems treat the C library as their "stable" API).
There was a time when it was --- there was a "Missile Command" game written for the 128K Mac which still ran fine in the Mac OS environment running the last version of MacOS on PowerPC machines:
and the previous version of Rosetta was for running PowerPC apps on Intel machines (and before that it was for handwriting recognition).
and I've always regretted that Macromedia Freehand didn't get re-written so as to run for longer --- that's one of the reasons I've pretty much switched to a Windows machine (using a Samsung Galaxy Book 3 Pro 360, which replaced a Book 12, which replaced a Toshiba Encore 2 Write 10, which replaced an Asus Vivotab Note 8, which replaced a Fujitsu Stylistic ST-4110, which replaced an ST-2300, &c.) I use a Wacom One w/ my MacBook, but it's just not the same.
Backwards compatibility on macOS is quite good. Whenever Apple breaks compatibility, they give a lot of notice, mark the functions in the headers as deprecated, then wait a fair amount of time before actually removing them. For apps that are continuously maintained, it’s not too huge of a burden to keep up with most of the time. For apps that are no longer in development, it can suck, for sure, to not be able to use an app after a breaking change, though.
I'd love to run GNUStep on my Linux machine simply because The NeXT heritage brings with it the only sane keyboard shortcut / keybinding system on the Linux desktop. Before I go on a tangent, let me link to NEXTSPACE [1] which is a CentOS based GNUStep OS. Sadly, since the author is from the Ukraine, all development has halted since last February :( I hope he is ok.
Now the keybinding tangent: If you're not rolling VIM keybindings in the whole desktop (which is tricky for non-modal interfaces and alienating a large amount of users), the next best ergonomic keybinding scheme is the Emacs / Gnu Readline system [2]. It allows moving the cursor without having to move hands around (e.g. going to the arrow keys, coming back to the alphabetical keys). It is one of the base tenets of unix systems. Every terminal supports it. Yet, the whole bunch of Linux Desktop systems completely ignored these keybindings and copypastaed the Windows concept instead, coming up with a weird chimera of readline in some places, and half-windows, half-self-invented in others.
Gnome used to have an Emacs compatibility mode that was somehow off by default and had to be enabled in a tweak. It was removed with GTK 4 however. If you want to do that in KDE, you have to run a weird python daemon, and half the apps constantly stop working because they key codes are being messed with.
MacOS on the other hand, supports these keybindings in every input dialog, it is a pleasure to use. Even more so, to have the same keybindings in every app and not having to learn new ones on a per-app basis.
Of course, running weird python key code daemons runs into the other problem that macOS & Gnustep solved in a much nicer way: By copying the shortcut system from Windows and patching it on top of Readline, many shortcuts have double entries. Printing is CTRL-P, but so is readline "Previous Line". macOS and Gnustep solve this by having a separate key for app actions: Command (or Hyper or Alt). So print is Command+P. Everywhere. Previous line is CTRL-P. This is always my go-to Linux joke where "Copy" is "CTRl-C" everywhere, except in the Terminal, where it's CTRL-SHIFT-C because yeah, CTRL-C has another meaning. Talk about a sane shortcut system if apps have to use different ones per shortcut because the amalgamation of Windows Shortcuts + Readline is a match made in hell.
Thanks for that rabbit hole of nostalgia, just remembered how wild Mac OSX 10.1 in its first release was. It was a real game changer, and looked great (albeit a bit slow on my poor G4 Cube).
I recall reading that the reason is that the mouse pointer is more likely to already be near the left of the window, because more of the text is on the left, especially in a programming language.
As others mentioned, this is due to the NextStep theme which is the default. However GNUstep supports other themes and can have the scrollbars at the right position too.
It actually doesn’t use WindowMaker. GNUstep is a reimplementation of core Apple frameworks, and can run in any DE (including Windows)
WindowMaker is its own thing that just so happens to be trying to recreate software from the same ecosystem as GNUstep, but they don’t depend on each other.
Combining them tho does give you that genuine experience
Three years ago I had passing interest in GNUstep, and in the past there have already been demos of so-called "Renaissance apps", which can compile against either AppKit or GNUstep. The GNU Mail program is one such program.
Wait till you learn Clozure Common Lisp has an Objective-C bridge and features a Mac IDE written with it. Unfortunately it has bitrotted over time as Apple constantly changes AppKit and some Objective-C internals, but it's able to run on Catalina just fine, and it works even better on older versions of OS X.
It seems Apple isn't immune to the "rewrite entire codebase from scratch". I'm not saying it is a good thing or a bad thing, but it is a trope of software companies.
Both true and false. The OS is not receiving updates, but Catalina and newer have a built-in malware scanning tool that does continue to receive updates from apple. You can read about that here.
There was a weird bug that took me forever to debug… and in the end, it was caused by some horrible bug in some map structure (NSDictionary? I think?) where a NSString unicode key did not map to the same value every time. Quite basic stuff. (It worked fine on Mac.)
As a student I didn’t really know how to report bugs, so I didn’t; I just wondered how did nobody catch it until now; but I just thought that probably nobody really uses GNUStep so that’s why.
It’s just anecdotal and I don’t really have access to the code anymore so I cannot tell you the details. (the original code was far from perfect too, maybe it was some unicode weirdness.)