Re: Thoughts about GNUstep

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)