On 2/25/25 15:25, Riccardo Mottola wrote:
Hello Richard,
Richard Stallman wrote:
Congratulations on the new release.
Thanks for your kind words.
GWorkspace (and combined with latest GNUstep Core) really got more
usable and stable with this release.
Is there an up-to-date list of the features that GNUstep needs and
lacks?
I would like to see it.
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,
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.
We have several bugs in GNUstep and in some major applications, but
let me share some concerns looking at GNUstep in the context of GNU
and Open Source in its future.
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 still don't understand what the issue is with LLVM. I'd assume it
would be much more useful to add support for weird platforms to LLVM
than to add Objective-C support for GCC, since adding support for those
weird platforms to LLVM would also allow more languages to target those
platforms than just ObjC (the biggest one for us would be Swift).
Additionally, swiftc is not designed to work with non-LLVM backends, and
I think it would probably be very difficult to either retrofit swiftc to
run on top of GCC or make a new Swift compiler for GCC. We have many
other issues to deal with, and I don't think working on GCC is a useful
endeavor right now (but I wouldn't be opposed if anyone wanted to work
on GCC more than they wanted to work on the GNUstep frameworks or
applications). Perhaps if we want GCC's platform support without writing
new LLVM backends, we could write an LLVM backend that produced GIMPLE
or some other suitable IR, but that might not really be feasible (I'm
not really familiar with compilers).
2) printing. Of the "classic" OpenStep/Cocoa features, this is the
biggest issue we have, it goes hand in hand with bad PostScript
generation
I haven't heard of this, but this sounds like an important to fix, yes.
Does it simply not work, or do we just generate bad PostScript and have
other terrible bugs which prevent it being useful?
3) Future of Cairo as a backend. Cairo itself seems in "maintenance"
Gtk still used Cairo until very recently, but see the four blog posts
https://blog.gtk.org/2023/09/19/paths-in-gtk/ through
https://blog.gtk.org/2024/01/28/new-renderers-for-gtk/ -- they are
transitioning to GPU-backed rendering (status for getting rid of Cairo
is at https://gitlab.gnome.org/GNOME/gtk/-/issues/7236).
Qt Quick (QML) used to be OpenGL-only, but it now uses QtGui's QtRhi
(which has OpenGL, Vulkan, Metal, and Direct3D 11 backends)
(https://www.qt.io/blog/qt-quick-on-vulkan-metal-direct3d). I think Qt
Widgets uses the QtGui 2D rendering features. I think Tk uses Xlib
directly, and its Windows backend is a fake Xlib. Flutter and Chromium
use Skia. I have no idea what .NET MAUI is using, but it's possible it
uses SkiaSharp. Of course SwiftUI, UIKit, and AppKit use Quartz.
I don't exactly know how the macOS/Quartz graphics stack works, but it
might be possible to use more of our Quartz reimplementations
(libs-quartzcore, libs-opal, etc) (it will be necessary to integrate
with them in order to port more complicated macOS apps anyways).
4) Wayland backend. We all love X11, but several distribution go the
Wayland path. First tests show that the X11 containers provided don't
work well with GNUstep. We either fix that or in the long run need a
native Backend for it
There is a Wayland backend in Back, but AFAIK it is still experimental.
XWayland has been working for me, but I think Wayland would probably
make it easier to have touch support, trackpad gestures, and some other
nice things, along with being more efficient by not using Xorg and being
able to send already-rendered bitmaps and textures straight to the
compositor without proxying them through Gui/Back and the GPU backend,
if we ever implement a GPU backend.
Note: this is just a thought for the future. I am not advocating
dropping support for GCC, PostScript, Cairo, X11 or whatsoever, but be
ready to extend to more, as in portable spirit.
Regards,
Riccardo
