I got my first PR into MathEdit for OpenStep today. Pretty exciting. This gentlemen was kind enough to add a makefile for GNUstep. He even included a screenshot.
https://github.com/jeffreybergier/MathEdit/pull/57
(https://private-user-images.githubusercontent.com/54595360/497584129-22ac5461-985d-445c-9af0-a32832922520.webp?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NTk3MTY5OTksIm5iZiI6MTc1OTcxNjY5OSwicGF0aCI6Ii81NDU5NTM2MC80OTc1ODQxMjktMjJhYzU0NjEtOTg1ZC00NDVjLTlhZjAtYTMyODMyOTIyNTIwLndlYnA_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUxMDA2JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MTAwNlQwMjExMzlaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1hN2U1OWExNmM2NjMyZTViNjQ3MjRiMzAyZTkyZmJlMjgxZjE5YjI0MTM0ZjUwZTYwMDJhZjkyYjI3YTllYjQ3JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.zKLDO5A1f6tuRXyXnWx_hC0I_CnbhdeIIb9DNf-RVXQ)
Congrats! At this rate GNUstep will finally get a spreadsheet program. ;D
I think this officially makes MathEdit the second most-ubiquitous OpenStep app, beating out Solitaire and AstroGC, and falling close behind that famous stalwart TextEdit. We just need to get some emulated SPARC and HP-PA machines spun up so we can get those OPENSTEP Enterprise for Solaris and OPENSTEP Enterprise for HP-UX builds going.
Quote from: jeffburg on Oct 06, 2025, 02:15 AMI got my first PR into MathEdit for OpenStep today. Pretty exciting. This gentlemen was kind enough to add a makefile for GNUstep. He even included a screenshot.
Sometimes it's worth it to raise some public attention: lists.gnu.org/archive/html/discuss-gnustep/2025-10/msg00014.html (https://lists.gnu.org/archive/html/discuss-gnustep/2025-10/msg00014.html).
In this case, the one to blame for making this gentleman aware of your project was yours truly. ;)
I hopefully look forward to include this unexpected GNUstep port of MathEdit in the upcoming release of wmlive based on Debian/Trixie.
Here is a quick screenshot with the GNUstep based MathEdit.app running on the current development version of wmlive-trixie.
MathEdit_on_Debian.png
MathEdit is a true proof of concept for the viabilty of GNUstep porting OPENSTEP and MacOS apps to Linux (and also Windows).
Well done, Jeffrey!
I'm amazed how good it looks. Like the reimplementation of AppKit seems incredibly accurate. I do have a question though... is this only possible because I don't have NIB's or can GNUstep inflate NIBs as well? What about XIBs?
Quote from: jeffburg on Oct 15, 2025, 11:29 PMI'm amazed how good it looks. Like the reimplementation of AppKit seems incredibly accurate. I do have a question though... is this only possible because I don't have NIB's or can GNUstep inflate NIBs as well? What about XIBs?
Gorm, the GNUstep counterpart to InterfaceBuilder, can load XIBs but not save them. In the early days, there was a tool for OPENSTEP called nib2gmodel (https://github.com/gnustep/tools-model-main) that used reflection to fire up the NIB and then re-record all its attributes in a special intermediary format that Gorm could import, but nib2gmodel requires a running copy of GNUstep for Mach to work. More recently the concept was revisited as nib2xib (https://github.com/gnustep/tools-nib2xib), which is a standalone tool; it might be useful for porting NeXT GUIs straight to modern macOS.
Of course, it would be
impeccably cool if someone could figure out how to reverse the process, but given that all both of tools seem to be designed specifically to avoid parsing the NIB file directly, and how unstable NIBs are between OS versions, I'm guessing that's not likely to happen without serious reverse-engineering effort. I suspect that if NeXT wanted the NIB format to be part of the OpenStep spec, GNUstep would have adopted it instead of developing an alternative.
Yeah, that's actually why I removed the NIBs from MathEdit. The NIB format changed a ton over time and it was not sustainable to have NIBs that worked in every version of Mac OS X.
Looks like it luckily also made MathEdit super compatible with GNUstep then :P
Approaching the last development stages for the release of wmlive-trixie, i've made an attempt to package GNUstep based MathEdit as a debian package for inclusion. In the absence of any release tarball i created some kind of wrapper package to download the current sources from github and using that for compilation.
There are a few things that i'd like to suggest changing on the github side of things:
- It would be great if all those screenshots, videos, and binaries for multiple platforms could be provided separately from the actual source code. We are speaking of a git clone volume of over 300 MB versus about less than 10 MB for the actual source code.
- Additionally, it would be much preferable if a tarball with some proper version number could be made available. Currently, i am using 0.${git-commit} as a crude versioning scheme for the package.
Unfortunately, the GNUstep based version of MathEdit is not very stable and easily crashes, for example sometimes when closing an open document. This might be rather an issue with the GNUstep libraries than MathEdit itself. In any case, someone knowledgable with GNUstep development would have to debug and stabilize the code before considering an actual release.
At the current state of affairs, i don't think it would be recommendable to release unstable Linux binaries of MathEdit with wmlive.
Thanks for the feedback. This is very fair. I kept all the binaries in the repo to make it easy for people to download and to make it so I don't need host anything. But you are right. In the future, I think I will make the releases repo a git submodule, that way I get the best of both worlds.
I wonder if there is a way I can make a MathEdit releases repo and put all of the releases in there and then purge them from the history. I am not familiar with current git cleanup tools.
As far as app crashing when the window closes... I am not entirely surprised.. these are issues I worked around in the real OpenStep environment. I ended up making some of the objects -dealloc methods work in not totally standard ways... such as using autorelease instead of release. Which is not needed. To make things worse, the workarounds needed to change when I removed the NIBs.
So I am not shocked at all that whatever window release issues OpenStep (that still live in OS X today for legacy reasons) are not perfectly reproduced in GNUStep.