Hi everyone, Congratulations on the new GWorkspace release. First, I want to say that I think GNUstep gets a lot of things right. Its focus on portability is fantastic. I’m grateful for its existence and only wish I had discovered it sooner.
My first encounter with GNUstep was through Étoilé, though I didn't realize at the time that Étoilé was built on GNUstep. For years after Étoilé ended, I remained unaware of GNUstep’s potential. My initial impression was that it was simply a NeXTSTEP clone and nothing more, so I didn’t explore it much further for along time. Inspired by LIVEstep, a friend and I started experimenting with those ideas, pushing them forward to see what else was possible. Before really digging into GNUstep, I had no idea it could look and function like this: https://raw.githubusercontent.com/pkgdemon/screenshots/refs/heads/main/gershwin-01.png Fork of the Sombre theme GNUstep handles window decorations without a separate window manager Modified gs-terminal to move the scrollbar to the right Running a newly written dock that supports showing running applications Or that it could also take on a completely different look and feel, like this other thing I've been hacking on: https://raw.githubusercontent.com/pkgdemon/screenshots/refs/heads/main/yellowbox-01.png Using XFCE4-wm for window management and decorations Modified the GTK theme engine to include Rik icons Modified gs-terminal to move the scrollbar to the right These projects have been quietly underway for some time, but I’d say the effort required to achieve this has been relatively trivial. As I’ve shared my work with friends, one particular conversation stands out. A Python developer who maintains a BSD distribution that ships with MATE had no idea that GNUstep supports Wayland. He isn’t particularly interested in NeXT- or Mac-style interfaces, but the more I’ve talked to him about what GNUstep can do regarding portability, and wayland the more interested he has become. Based on these experiences I do think better communication of what GNUstep is and what it can do would greatly help. As a junior level programmer, I have found applications build with GNUstep much easier to understand and more pleasant to modify and work with than, say, Qt-based projects. If I had to rank the ideas mentioned so far including my own ideas, these would be at the top of my list (in no particular order): Improved integration and experience for applications with other free desktops Continued GCC compatibility More accessible and complete documentation for developers and packagers Expanded Wayland backend support and better integration with existing compositors That said, GNUstep has survived many years. Whichever ways are decided to move forward my personal wish here would just to somehow see a result that ends in more applications developed for or ported to GNUstep. I do not have the experience to know if these are the right answers but those are the things that stand out to me as things that could attract more developers if that is a goal. Joseph Maloney Sent with Proton Mail secure email. On Friday, February 28th, 2025 at 8:55 PM, Ethan C <[email protected]> wrote: > Hi, > > On 2/27/25 20:58, Richard Stallman wrote: > > > > A lot of people would answer (and did) comparing to Apple and missing > > > features. I would to stress some pain points which we need regardless, > > > > What does it mean to say that something is a "pain point" and we "need it"? > > In general, I think of pain as something we would rather not have. > > I believe "pain points" are features which are "painful" because we do > not have them, or bugs that we do have that are "painful" because they > cause significant issues. In this case, the pain points are features > that we need or will need in the near future in order for GNUstep-GUI to > be a viable GUI library, at least as I understand it. > > > > especially since it is my opinion that Apple is diverging and either we > > > get e.g. Swift in GCC or Clang or it makes little sense to pursue that > > > road too wildly, the future of Cocoa might be uncertain. > > > > It sounds like you are saying that GNUstep is good in its own terms, > > but without the compatibility we with recent Apple systems. Is that > > right? > > > > I have nnly the vaguest idea of what Swift and Cocoa are, so I can't > > really grasp the significance and implications of this. > > > It is more that Apple seems to be abandoning the technologies that we > have been reimplementing both because it is useful to have Apple > compatibility and because we think those technologies were well-designed. > > For context, the GNUstep project is a reimplementation of Cocoa which > works on most Unix-like systems that have X11, and also works on > Windows. Cocoa is the core of the macOS libraries made available to > application developers -- it includes Foundation (the standard library, > which also contains networking facilities and many other common > utilities; our implementation is GNUstep-Base), AppKit (the GUI library; > our implementation of the high-level parts is GNUstep-GUI and the actual > rendering of the GUI is in GNUstep-Back), CoreData (a database library; > our implementation is GSCoreData), and many other useful libraries. > > For example, most of the GNUstep contributors particularly like the > Objective-C programming language. In 2014, Apple introduced the Swift > programming language which has Objective-C compatibility but has a much > more C++-like memory model and makes many C++-like decisions. > Additionally, they have begun reimplementing Foundation in Swift. > > Another major thing is that they have created a new GUI framework called > SwiftUI on top of AppKit (which is the one that GNUstep-GUI reimplements > and extends), which requires Swift and uses the declarative/reactive > paradigm rather than the model-view-controller paradigm. They have > started to create libraries which provide SwiftUI-only GUI controls. > SwiftUI is becoming increasingly popular amongst developers for the > Apple platforms, since it is easier to create simple applications using > it, and complex applications can implement the simple parts in SwiftUI > and implement the more difficult parts in AppKit. > > This brings up the question of whether we want to reimplement Apple's > newer ideas which are based on a different paradigm than what we are > used to, or if we want to extend the old platform and get rid of our > goal of compatibility with applications written for Apple systems. > > > > 1) Continued GCC support, with (gradual?) adoption of features missing > > > in the runtime as well as bug fixes and certainty of support. This is an > > > important issue for GNU, or, as you know, we can only use clang for > > > them. We still support GCC, but it is not acceptable that it is stuck in > > > time. > > > > I consider it unacceptable that we depend on Clang for anything. > > But I don't know how to find anyone who wants to work on Objective C. > > I don't get the problem here. Clang is free software. Its Objective-C > compiler is more mature than GCC. It works well on both GNU/Linux and on > most other Unix systems. It uses LLVM, which is well supported and is > the basis for many other languages, including Swift -- it would probably > be infeasible to make a GCC Swift compiler unless the GNUstep project > became suddenly much bigger. > > > To work on that part of GCC is not terribly hard. You need to learn > > only a small part of the compiler and a few of its data structures > > and interfaces. > > > > Would you like to give it a try? It sounds like GWorkspace has > > reached a good resting point, I can probably find a GCC developer to > > explain the data structures and how to operate on them. > > > > What is Cairo? > > Cairo is the 2D graphics library that GNOME's Gtk GUI framework uses. > Additionally, WebKitGtk, Firefox, and many other applications used to > use it, but many of them have switched to using 3D graphics APIs like > OpenGL or Vulkan, or switched to other libraries like Skia. Gtk is > currently trying to get rid of Cairo, so once that's complete it might > become unmaintained. Since GNUstep-Back uses Cairo to render the GUIs > which our applications using GNUstep-GUI create, it might be necessary > to switch to an actively maintained 2D graphics library.
