Re: Thoughts about GNUstep

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