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.
