7 ms·

GNUstep compatibility with macOS Catalina almost complete

169 points by pabs3 4y ago

LysPJ 4y ago
An explanation of what GNUstep is (and what it is not): https://gnustep.github.io/information/aboutGNUstep.html https://gnustep.github.io/information/aboutGNUstep.html
- irusensei 4y ago
  This is informative. I was thinking I was familiar with GNUStep when in fact I was thinking about WindowMaker.
ginko 4y ago
So does that mean that macOS Catalina apps can run in a GNUstep environment or that GNUstep apps can run in macOS Catalina?
- hibbelig 4y ago
  I think it’s about source code level compatibility: macOS software can be compiled for GNUstep.
  - agsnu 4y ago
    Of course Swift is now almost a decade old, so it's increasingly rare to find a pure Objective-C codebase
    - deleted 4y ago
      [deleted]
awestroke 4y ago
Catalina is no longer receiving updates
- gattilorenz 4y ago
  “The reason this is still significant is because Apple hasn't made many changes to either the Foundation or AppKit APIs since then.” And to be honest, I expected GNUstep to chase Lion or something, I had no idea there has been so much progress lately. Did anyone here use it?
  - koito17 4y ago
    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.
    - lispm 4y ago
      > Wait till you learn Clozure Common Lisp has an Objective-C bridge and features a Mac IDE written with it. LispWorks has that, too. Without the bitrot. It's running natively on current Apple Silicon Macs. See the manual: LispWorks Objective-C and Cocoa Interface User Guide and Reference Manual http://www.lispworks.com/documentation/lw80/objc/objc.htm http://www.lispworks.com/documentation/lw80/objc/objc.htm
    - BaculumMeumEst 4y ago
      too bad ccl has no plans to be ported to arm afaik
  - pjmlp 4y ago
    Naturally, with exception of Metal and Driver Kit, all new toys are based on Swift, or frameworks shared with iOS.
  - rdsnsca 4y ago
    Foundation is going to be redone in Swift. https://www.swift.org/blog/future-of-foundation/ https://www.swift.org/blog/future-of-foundation/
badsectoracula 4y ago
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
- JonChesterfield 4y ago
  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.
shp0ngle 4y ago
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.)
- stuaxo 4y ago
  This is my experience using open source in general, as a developer (who mostly uses open source).
  - nailer 4y ago
    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”
    - nailer 4y ago
      Not complaining about moderation but I do wonder why someone would disagree with the advice above.
      - sebastien_b 4y ago
        [dead]
  - KyeRussell 4y ago
    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’.
random_ua 4y ago
Does anybody know why they show scrollbars at the top and left of the scrolling area, unlike any other UI ?
- Rochus 4y ago
  In Smalltalk-80 they're on the left side, see e.g. https://github.com/rochus-keller/Smalltalk https://github.com/rochus-keller/Smalltalk As is known, Jobs was inspired by the Smalltalk GUI.
  - kps 4y ago
    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.
- cowsandmilk 4y ago
  GnuStep uses WindowMaker, which shows scroll bars on bottom and left because that’s where they were on nextstep.
  - bogwog 4y ago
    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
  - badsectoracula 4y ago
    Note that Window Maker is a completely separate project with its own GUI toolkits (WINGs - it literally means "WINGs Is Not GNUstep" :-P).
- mpweiher 4y ago
  That's where they were on NeXTStep: http://toastytech.com/guis/ns332.html http://toastytech.com/guis/ns332.html And it's actually a pretty good place. Just like the whole "a menu is just a window with a list of buttons" idea was great.
anthk 4y ago
I miss the GNUStep live CD. Sometimes I wish Gnome wasn't created as a libre KDE alternative and a GNUStep/WMaker based DE would grow up.
- Gordonjcp 4y ago
  Why not go further, and just use Haiku? Then you're not even using anything as mainstream as Linux!
deleted 4y ago
[deleted]
terhechte 4y ago
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. [1]: https://github.com/trunkmaster/nextspace https://github.com/trunkmaster/nextspace [2]: https://en.wikipedia.org/wiki/GNU_Readline https://en.wikipedia.org/wiki/GNU_Readline
- anthk 4y ago
  >arrow keys sane people will just use hjkl even on readline with ~/.inputrc and 'set -o vi' in ksh.
yawaramin 4y ago
> As the much villified theme for star trek enterprise says "its been a long road getting from there to here" Off topic, but I actually really like Russell Watson's 'Faith of the Heart'. I mean, how can you not?! https://www.youtube.com/watch?v=M6bumUQwQIU https://www.youtube.com/watch?v=M6bumUQwQIU

169 points by pabs3 4y ago

An explanation of what GNUstep is (and what it is not): https://gnustep.github.io/information/aboutGNUstep.html https://gnustep.github.io/information/aboutGNUstep.html

irusensei 4y ago
This is informative. I was thinking I was familiar with GNUStep when in fact I was thinking about WindowMaker.

ginko 4y ago

So does that mean that macOS Catalina apps can run in a GNUstep environment or that GNUstep apps can run in macOS Catalina?

hibbelig 4y ago
I think it’s about source code level compatibility: macOS software can be compiled for GNUstep.
- agsnu 4y ago
  Of course Swift is now almost a decade old, so it's increasingly rare to find a pure Objective-C codebase
  - deleted 4y ago
    [deleted]

awestroke 4y ago

Catalina is no longer receiving updates

gattilorenz 4y ago
“The reason this is still significant is because Apple hasn't made many changes to either the Foundation or AppKit APIs since then.” And to be honest, I expected GNUstep to chase Lion or something, I had no idea there has been so much progress lately. Did anyone here use it?
- koito17 4y ago
  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.
  - lispm 4y ago
    > Wait till you learn Clozure Common Lisp has an Objective-C bridge and features a Mac IDE written with it. LispWorks has that, too. Without the bitrot. It's running natively on current Apple Silicon Macs. See the manual: LispWorks Objective-C and Cocoa Interface User Guide and Reference Manual http://www.lispworks.com/documentation/lw80/objc/objc.htm http://www.lispworks.com/documentation/lw80/objc/objc.htm
  - BaculumMeumEst 4y ago
    too bad ccl has no plans to be ported to arm afaik
- pjmlp 4y ago
  Naturally, with exception of Metal and Driver Kit, all new toys are based on Swift, or frameworks shared with iOS.
- rdsnsca 4y ago
  Foundation is going to be redone in Swift. https://www.swift.org/blog/future-of-foundation/ https://www.swift.org/blog/future-of-foundation/

badsectoracula 4y ago

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

JonChesterfield 4y ago
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.

shp0ngle 4y ago

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.)

stuaxo 4y ago
This is my experience using open source in general, as a developer (who mostly uses open source).
- nailer 4y ago
  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”
  - nailer 4y ago
    Not complaining about moderation but I do wonder why someone would disagree with the advice above.
    - sebastien_b 4y ago
      [dead]
- KyeRussell 4y ago
  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’.

random_ua 4y ago

Does anybody know why they show scrollbars at the top and left of the scrolling area, unlike any other UI ?

Rochus 4y ago
In Smalltalk-80 they're on the left side, see e.g. https://github.com/rochus-keller/Smalltalk https://github.com/rochus-keller/Smalltalk As is known, Jobs was inspired by the Smalltalk GUI.
- kps 4y ago
  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.
cowsandmilk 4y ago
GnuStep uses WindowMaker, which shows scroll bars on bottom and left because that’s where they were on nextstep.
- bogwog 4y ago
  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
- badsectoracula 4y ago
  Note that Window Maker is a completely separate project with its own GUI toolkits (WINGs - it literally means "WINGs Is Not GNUstep" :-P).
mpweiher 4y ago
That's where they were on NeXTStep: http://toastytech.com/guis/ns332.html http://toastytech.com/guis/ns332.html And it's actually a pretty good place. Just like the whole "a menu is just a window with a list of buttons" idea was great.

anthk 4y ago

I miss the GNUStep live CD. Sometimes I wish Gnome wasn't created as a libre KDE alternative and a GNUStep/WMaker based DE would grow up.

Gordonjcp 4y ago
Why not go further, and just use Haiku? Then you're not even using anything as mainstream as Linux!

deleted 4y ago

[deleted]

terhechte 4y ago

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. [1]: https://github.com/trunkmaster/nextspace https://github.com/trunkmaster/nextspace [2]: https://en.wikipedia.org/wiki/GNU_Readline https://en.wikipedia.org/wiki/GNU_Readline

anthk 4y ago
>arrow keys sane people will just use hjkl even on readline with ~/.inputrc and 'set -o vi' in ksh.

yawaramin 4y ago

> As the much villified theme for star trek enterprise says "its been a long road getting from there to here" Off topic, but I actually really like Russell Watson's 'Faith of the Heart'. I mean, how can you not?! https://www.youtube.com/watch?v=M6bumUQwQIU https://www.youtube.com/watch?v=M6bumUQwQIU