Re: Thoughts about GNUstep

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