Re: Thoughts about GNUstep
Michael Rans <[email protected]> Mon, 4 May 2026 15:10:15 +1200
| Newsgroups | gmane.comp.lib.gnustep.general |
|---|---|
| Message-ID | <[email protected]> |
Greg, I'm glad my input could be of help. Thanks very much for your reply and good to meet you too! I stand on the shoulders of giants with regard to Oolite development - my work has been to modernise it as it had basically stopped working on Linux leaving only a Windows build that relied on copying a decade old dev environment folder with various customisations in it. Maybe a phased approach could work? Start by making clang the default. Then approach GCC to say that without ObjC2.0 support, GNUstep will have little choice but to deprecate support for GCC. If they say they will try to upgrade GCC to ObjC2.0, then keep clang the default until such time as they complete it. If they will not look into it, then go ahead with deprecation. I have no idea about the politics though. Cheers, Mike (ccing the mailing list this time) On 04/05/2026 03:19, Gregory Casamento wrote: > Micheal, > > On Sat, May 2, 2026 at 10:49 PM Michael Rans <[email protected]> wrote: > > Hi all, > > Putting myself in the shoes of a new developer finding out about > GNUstep for the first time, I imagine that the first contact they > will have with it is by way of installing it via their system > package manager on Linux. This will give them a gcc build of > GNUstep. They will then discover that it supports an old version > of Objective-C. > > Currently, GNUstep supports ObjC2.0 when using clang. Your saying > that demonstrates something I know about GNUstep and that is that our > ability to say what we are and what we support is difficult to convey > and our website is not making this clear enough. Also, Debian and > other Linux distros have been very slow in allowing the use of clang > by default. This is frustrating because we are NOT in control of the > compiler. GCC remains compatible ONLY with ObjC1.0 and they have made > little movement towards supporting ObjC2.0. > > At this point, the developer may lose interest and look for > something else. So in my view, the clang version of the libraries > should be the default on all distros with the gcc version as an > option. > > Agreed, and this IS our fault. Some people might argue that this > shouldn't matter, but I, personally, think that it is very important > for us to either get ObjC2.0 into GCC *OR* drop support for it > entirely. Dropping support is difficult, politically, since we ARE a > GNU project. > > That would suit us developing Oolite as although the game now > builds on both gcc and clang (thanks to the great support I > received from GNUstep devs), the primary target is clang and one > day we may drop support for gcc if keeping it running becomes too > much of a hassle. Building the GNUstep libraries from source is > not so convenient. > > I agree... we have a lot of work to do with respect to packaging with > distros and getting the version of GNUstep out there that we need to > get out. > > If GNUstep is to be a multi-OS app platform, I think it will need > to support interop with popular languages like Rust and C++ well. > > > Oh wow.. I love OOLite, nice to meet you. :) > > Well... we have that with C++ as we have ObjC++. With Rust they can > call our stuff from Rust using C-based functions, but that is messy > and not desirable. > > Mike > > > Thank you so much for your input, it is highly valued. > > Yours, GC > > On 02/05/2026 13:08, James Carthew wrote: >> Hi Patrick, >> >> I can answer some of that. From what I've observed on here over >> the last 20 years different people have different >> goals/perspectives on what they are creating and why. There is >> also a difference in the approaches used. >> >> - GNUstep has been running for 35 years. There are internal >> divisions among contributors about NEXT vs Mac OSX and maybe some >> closet WindowsNT style people ;) There's definitely division over >> Objective-C 1.0 vs 2.0 and whether to use ARC, Grand Central >> Dispatch etc. GNUstep is a big tent and that's OK. >> >> - Distro/API/Desktop GNUstep is an API, NEXTSpace is a NextSTEP >> Desktop, Ambrosia is a Mac-Like Desktop, there has been talk of a >> GNUstep Distribution and some ISOs have been created for that. >> >> - Linux is not really a neutral Unix platform anymore, for a >> number of years now it's been moving in a guided direction pushed >> by IBM/Redhat but also by user adoption. e.g >> SystemD/Wayland/Pipewire etc. >> >> - GNUstep has always maintained neutrality with different Unixes, >> e.g FreeBSD/OpenBSD/Linux/Darwin etc. I suspect this is why >> SystemPreferences.app has never implemented >> Audio/VIdeo/Networking controls. There is also as far as I'm >> aware no underlying VideoKit/AudioKit/NetworkKit libraries for >> driving those systems. Rather than re-write SystemPreferences.app >> I've taken the approach of making compatible plugins for it, I >> don't know Pipewire/NetworkManager/Wayland/X11 at a deep level so >> I've heavily relied on AI for developing these plugins. I don't >> know how many programmers that are across Objective-C are across >> these technologies, I suspect it's a very small number if any. >> >> - Etoile was the closest attempt at what I'm trying to do. They >> had some really fantastic progress at building a modern mac-like >> environment built on the GNUstep libraries that existed at that >> time. All of these projects have histories and the people >> involved put their heart and pride into their work so I won't >> speculate on what happened, things changed/shifted. Etoile's >> screenshots are what motivated me to start on this path. >> >> - I have always thought that WindowMaker is not fit for purpose. >> WindowMaker is built around NextSTEP and I've always been >> unsatisfied with it's lack of Objective-C API support, lack of >> integration into SystemPreferences.app and lack of support for >> using the GNUstep themes as the Theme for WindowMaker. >> This is why I've built my own Compositor and I'm targeting >> Wayland. My compositor is also going to use the GNUstep theme to >> skin the windows of X11 and Wayland applications. >> >> - Ambrosia dock is actually a floating dock, every image showing >> it at the bottom is just where I've placed it from habit, there >> are options to make it a vertical dock and move it to the sides. >> Eventually I have plans to make the dock completely optional. >> >> - GWorkspace is based on NEXT ideas/UI philosophy. Initially I >> modified it by just shuffling a shelf off to the left but I've >> basically forked it now into GFinder and stripped out features >> that I don't want to continue with e.g the GWorkspace Dock and >> continued to modify the UI. Unfortunately there are some things >> where work is going to be duplicated because NEXT and OSX are so >> different it doesn't make sense to use the same codebase for both >> anymore. >> >> - The Wayland backend is very unstable. I'm using Ambrosia as a >> daily-driver desktop to force myself to eat my own dog food and >> find issues to fix. There are many. All the file open dialog and >> alert windows are closing/disappearing before they can be clicked >> on (I've confirmed this is happening on Wayfire and Ambrosia and >> looks to be the backend causing it). gMPV.app has had to be >> developed by running the program from CLI and sending it the file >> paths e.g openapp gMPV.app ~/Videos/*.mp4 to test a list of video >> files. I had to have AI analyse the X11 backend and implement >> Wayland support for NSOpenGLView on Wayland and I then had to >> extend it further to enable Hardware accelerated GPU buffers for >> Video. I don't think many people are using the Wayland backend >> for serious application development. e.g Gershwin seems to be >> targeting X11. >> >> - I'm heavily using AI for my development of Ambrosia. I know a >> lot of people have moral/ethical objections to this, and as a >> result are likely working within their personal programming >> skillsets on their projects. I do think that developing your >> skills as a programmer is something worth doing and it is worthy >> of respect and I would never develop/release AI generated code >> under a non-open source license. I don't believe in profiting off >> of the work of the open source community with AI generated code. >> >> - Never feel you can't contribute, new contributors are always >> welcome. GNUstep is a big tent and there's plenty of things to >> hack on, everything from Documentation, Art, Code to UX design is >> important and valuable. >> >> On Sat, 2 May 2026 at 07:05, Joseph Maloney <[email protected]> wrote: >> >> I should clarify one thing. GNUstep is allowing me to build >> the kind of desktop experience that I want, that I could not >> do with any other solution today. It doesn't mean I didn't >> have to change or modify applications to get there, or make >> new solutions but that is part of the fun! >> >> Joseph Maloney >> >> >> >> Sent with Proton Mail secure email. >> >> On Friday, May 1st, 2026 at 4:00 PM, Joseph Maloney >> <[email protected]> wrote: >> >> > Speaking entirely unofficially as a contributor I don't >> have a problem with mailing lists. I think the monthly >> meetings are fine. When contributing small fixes here and >> there to core libraries my experience has been really good >> especially lately. >> > >> > I like that GNUstep is efficient, easy for me to learn, >> become fascinated by the more I learn, builds fast on lower >> end systems, and works well to build cool things around. I >> can't think of a single thing I would what I would even want >> to change, if I could. I guess I am not really wanting to >> change GNUstep personally ever and I do not personally need >> it to change for Gershwin Desktop. It already empowers me >> more than any other solution ever could. I just wanted to >> say that as something positive. >> > >> > Joseph Maloney >> > >> > Sent with Proton Mail secure email. >> > >> > On Friday, May 1st, 2026 at 12:09 PM, Patrick CARDONA >> <[email protected]> wrote: >> > >> > > Hello Greg, >> > > Hello Steppers, >> > > >> > > On 2026-05-01 11:55:33 +0200 Gregory Casamento >> <[email protected]> wrote: >> > > >> > > > All, >> > > > >> > > > I've been thinking about this recently about GNUstep, >> its path to success >> > > > and where it needs to improve. First I will cover what >> GNUstep is and what >> > > > you already know... >> > > > >> > > > GNUstep's greatest advantage is that it is *not just >> another desktop*. It >> > > > is a *complete application framework* with a coherent >> philosophy: >> > > > Objective-C, AppKit/Foundation-style APIs, visual UI >> tools, and a desktop >> > > > environment built around applications rather than >> around shell chrome. >> > > > >> > > > Its strongest advantages: >> > > > >> > > > 1. *It has a proven design lineage* >> > > > GNUstep follows OpenStep/Cocoa ideas, the same >> family of APIs that >> > > > influenced macOS. That means it inherits a mature >> object model, MVC-style >> > > > UI design, delegates, responders, services, bundles, >> nib/gorm-style >> > > > interfaces, and clean application architecture. >> GNUstep describes itself as >> > > > a cross-platform, object-oriented development >> environment compatible with >> > > > Cocoa/OpenStep concepts. >> > > > 2. *It can offer something many open source/free >> software OSes still >> > > > lack: a stable native app platform* >> > > > GNOME has GTK/libadwaita. KDE has Qt. Electron has >> the web stack. But some >> > > > open source/free software OSes still lack one >> dominant, elegant, >> > > > long-lived desktop application model. GNUstep’s >> pitch is stronger if it >> > > > becomes the “write real desktop apps again” platform. >> > > > 3. *Objective-C is somewhat underrated for >> systems-level GUI work* >> > > > Objective-C is a thin layer over C with dynamic >> messaging, which makes >> > > > it powerful without the complexity of C++. GNUstep’s >> own wiki emphasizes >> > > > that Objective-C is a strict superset of C. >> > > > 4. *It is portable by nature* >> > > > GNUstep's framework is intended to hide >> architectural differences and >> > > > allow code to be ported across platforms. That >> matters because a successful >> > > > development system cannot be single-platform forever. >> > > > 5. *It has a complete “small but real” ecosystem* >> > > > GNUstep has Foundation/Base, AppKit/GUI, Gorm, >> ProjectCenter, >> > > > GWorkspace-style tools, and modern desktop efforts >> like GNUstep >> > > > Desktop/GSDE, >> > > > Gershwin, Ambrosia, etc. that assemble the pieces >> into a usable >> > > > environment. >> > > > >> > > > The cold, hard truth is: *GNUstep will not succeed >> merely because it is >> > > > better designed.* It succeeds only when/if it becomes >> easier, prettier, >> > > > better documented, and more practical than >> GTK/Qt/Electron for real >> > > > developers. I have said many times before that >> sometimes people will stick >> > > > with "good enough" even when something better comes >> along UNLESS that thing >> > > > is SO compelling that they are forced to reconsider. >> This is the challenge >> > > > we are facing. >> > > > >> > > > *GNUstep can succeed where other desktops struggle >> because it can be both a >> > > > desktop and a disciplined application platform.* GNOME >> and KDE are >> > > > excellent desktops, but GNUstep’s deeper opportunity is >> to become the >> > > > free-software equivalent of Cocoa: a coherent native >> framework where apps >> > > > feel integrated, code remains understandable, and >> developers can build >> > > > serious desktop software without dragging in a browser >> engine. >> > > > >> > > > Swift is where GNUstep’s long-term story either becomes >> *compelling* or >> > > > *irrelevant*—there’s not much middle ground. We need >> to explore options >> > > > for swift compatibility. I realize many don't like >> this. I, personally, >> > > > don't like swift very much, but, for better or worse it >> is something that >> > > > many developers are highly attracted to. >> > > > >> > > > Key Points: >> > > > * Its path to success is *NOT* nostalgia for *NeXT*. >> > > > * Its path is: *Cocoa-like productivity, GNU freedom, >> modern packaging, >> > > > polished apps, excellent docs, swift compatibility, and >> a stable API that >> > > > developers can understand and trust.* >> > > > >> > > > I realize that much of this might sound harsh, but it >> is only out of love >> > > > for this project that I am saying what I am. I further >> realize that much >> > > > of this is antithetical to what some people on this >> project believe. >> > > > Fortunately or not, sometimes the technologies that >> succeed are NOT the >> > > > ones that we would wish. >> > > > >> > > > I am hoping this sparks real and PRODUCTIVE discussion >> instead of endless >> > > > email threads defending a given position. >> > > > >> > > > Yours, GC >> > > > >> > > >> > > I agree to take advantage of the incoming birthday to >> consider strategic choices and to improve our communication >> model. >> > > >> > > I am namely concerned by several aspects of the project. >> > > >> > > - In the Desktop side: we have already clever and >> inspirant people working on famous projects: Sergii Stoïan, >> Ondrej Florian, Probono and the Gershwin Team, James >> Carthew... sorry to the other I omit by ignorance. As a >> beginner, I did not dare to include myself. >> > > Also Maybe Zoë Mszoeck team? >> > > Unfortunately, such time and energy are often consumed to >> recreate separately the same bricks: a Dock, a Preferences >> Panel, a Topbar, a Terminal, a Workspace and a FileViewer... >> I dream all these clever people could cooperate and >> contribute to a same goal: a strong and efficient Desktop-Kit >> and a Desktop specs set approved by and reverted to the >> community, because until now, so many forked things tends to >> never get back although their authors think that could be. In >> reality, it never happens. >> > > - In the same consideration, why so many desktop projects >> rewrite parts of Window Maker? It could be more efficient to >> define our needs and to have a modus of pulling request to >> the Window Maker team. Otherwise, if we consider the need of >> a new or more modern window manager, we should select one and >> contribute to it the same way. >> > > >> > > - In the Theming and the easthetic side: well, >> screenshots are importants. But ergonomy is too, is more. >> While modern screens are wider, I think using the left and >> right sides is an evidence. Why aping MacOS bottom Dock? Why >> using pop-up notifications while we have badges or docked >> apps refreshing their icon contents? I think a real debate on >> such choices is important, because We need to claim our >> identity, not in terms of heritage, but in terms of >> efficiency and good concepts. The defunct Étoilé project was >> such an inspirant thing: a consistent and well conceived >> project, with a great visual identity. Well, if most of the >> community members want really a MacOS like, I will accept >> and try to help this too. We must stop dispersing. >> > > >> > > - In the learning curve, how could newbies like me learn >> efficiently to progress and to adopt GNUstep as their >> preferred framework and developer workshop. I think the >> Developer documentation could be improved: dead links, >> incomplete specifications. And what about those duplicate >> repos like: https://github.com/gitGNU/libobjc2 ? People could >> be lost. To be more positive, I appreciated tutorials and I >> found the Github IA (DeepWiki) too to be helpfull to retrieve >> or to understand GNUstep code. It could be a way to point >> out. Unlike many other IA I tested, it was more acurate on >> the proposals, namely distinguishing legacy and modern >> objective-C syntax. >> > > >> > > - Before attempting to introduce swift bridge, if we >> consider libobjc2 is the expected objective-C specification >> and runtime level for incoming developers, we should provide >> a consistent help to install it everywhere. By example, >> several scripts provided by Patryck Laurent became outdated. >> We could help him to update those. >> > > >> > > - Last consideration, but in the same spirit: could we >> envisage to rapproch our community to other projects like >> Cocotron, Mulle? Again, it is a great pitty to envisage >> developers having the same goal and the same programing >> language taste to be not joined in the same community. >> > > >> > > I hope to have contributed in the way expected. >> > > >> > > Cheers, >> > > Patrick >> > > >> > > -- >> > > Patrick Cardona - Pi500 - GNU/Linux aarch64 (Debian 13.4) >> > > Xorg (1:7.7+24) - libcairo2 (1.18.4-1+rpt1 arm64) - >> Window Maker (0.96.0-4) >> > > GWorkspace (1.1.0 - 02 2025) - Theme: AGNOSTEP - Classic >> - MUA: GNUMail (1.4.0 - rev.947) >> > > >> > > >> > > >> > > > -- > Gregory Casamento > GNUstep Lead Developer / Black Lotus, Principal Consultant > http://www.gnustep.org - http://heronsperch.blogspot.com > https://www.openhub.net/languages/objective_c