Re: Thoughts about GNUstep

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

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.

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.

Mike

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