Re: GNUstep on Hackernews

[Ivan Vučica]

On Sun, Dec 19, 2021 at 3:48 PM Liam Proven <lproven@gmail.com> wrote:
> GNUstep also has a packaging system, which is the reason I discussed
> it in my article.

I'm unaware of a packaging system in GNUstep; I admit not to know of
everything or keeping up with everything in GNUstep, however.

I'm also unaware of the article being referred to; I admit not to
reading the entire (excessively long) thread. Could you kindly share
the link again?

>
> If you are wondering how to "market" it _to programmers_ these days,
> then I suspect the answer lies in supporting newer languages than
> Obj-C.

I wrote a really long reply, then somehow managed to press a keyboard
shortcut to wipe it all.

I'll try to keep it shorter: [[remark after writing the below: hah,
it's even longer]]

There aren't that many dynamic languages that can have bridges to make
proper use of the interesting things in Objective-C and GNUstep-GUI:
- classes referred to by strings (NSClassFromString)
- classes visible as (near-)equal citizens on both sides of the bridge
- bindings working correctly (I want to observe a property from a
bound GS view, update the view based on the property value, update the
property based on the user-supplied value in the view)

Languages have to have appropriate syntax, ease of registering new
classes, ease of invoking methods based on names stored in strings,
...

Otherwise, what are we porting to other languages, exactly, and why?

> Swift is the obvious one:
> https://github.com/apple/swift-system

This requires someone to be intimately familiar with Clang and LLVM,
our libobjc2 runtime, Swift itself, and the bridge Apple has built for
macOS, but (to my knowledge) not for other platforms.

There is a magician around that fits this description, but I suspect
if he were interested, he'd take a stab at it. I've no useful
knowledge in Clang, LLVM codebases; my familiarity with Swift is
minimal (peeking at it, likely quick to acquire, but as of 2021 I have
yet to find a motivating project to learn practical Swift with; why
would I spend time on it? and more importantly, if I do, I have no
motivation to dig into low level cobwebs of the language required for
implementing something like a bridge), or a development environment
(containing Clang, LLVM, ...) to produce anything resembling something
useful.

I am not a compiler developer or researcher, I am barely familiar with
the basics of how an overly simplified ObjC runtime works (hello
Metrowerks m68k runtime from the 90s) -- enough to do some weird
tricks in apps, not enough to implement this.

I also don't properly know x86 assembly or ABIs, likely required to
produce a working bridge -- or even port Apple's bridge (is it
released?) from macOS to other platforms. macOS ABIs are, to my
knowledge, also different.

Again, to summarize: This suggestion requires an extremely, extremely
specialized set of skills and I can only personally think of one
person who I suspect might be able to do it.

(Of course, if someone convinces Apple that, having ported Swift to
Linux, they could also support at least one ObjC runtime available on
Linux...)

>
> Ones that might interest people in RAD and so on...
> • Kotlin perhaps?

I have a passing familiarity with Java, but try to steer clear of JVM
languages. Does JIGS bridge to Java still work and does it also make
GNUstep libraries work with Kotlin, as well?

> • Python, obviously

Someone announced PyObjC a few years ago.

> • Rust and Go up to a point -- trendy but maybe not so much for GUI apps?

I am unfamiliar with Rust, but a few words on Go. Simplified, likely
inaccurate, but possibly worth sharing.

Goroutines, channels and GC work with a runtime. It takes control over
the entire process. Jumping into C is possible and supported -- but
discouraged. You can define C functions callable from Go, and you can
call Go functions from C -- but this messes with the scheduler.

Our GNUstep-GUI would not have a good time getting stuck in there,
with its runloop etc.

And this is without taking into account that Go is rather... static.
No "I will load a .dylib/.so and a bunch of classes will appear and be
magically reachable with NSClassFromString, which is passable as the
receiver in the [message send:] expression". Reflection packages are
there, so you can refer to a type dynamically -- but you can't write
code "I will load this and you just trust me the message send will
work at runtime". Yes, hackable with interfaces and reflection, but
not Go-like.

Go also has no real inheritance.

None of this is a problem if you're using Go for what it's meant to be
used. It's an improved C, but improved in a different way, for a
concurrent world.

This is not what ObjC is great for (which is UIs and bindings, while
still using C or -- gasp -- C++). Specifying which NSDocument class
you want to load for a particular document type just seems silly. And
bending our backs to port a system that works great for Objective-C
(GNUstep-Base, -GUI) into Go when it's just going to be subpar seems
pointless, at least to me.

At that point, it may make as much sense to use glibc and GTK from Go,
which are at least built to be used in C.

I tried, out of interest in using libpurple in Go -- and even that is
barely really worth it.


Objective-C as a language is not necessarily a barrier if there are
true advantages to using it, and as long as apps don't feel foreign.

I mean here's a realistic wishlist:

- A desktop session
  - ship a package that contains
/usr/share/xsessions/gnustep-desktop.desktop e.g. 'gnustep-session' or
'gnustep-desktop-session'
  - have it start our chosen WM, gworkspace with dock, a global
dbusmenu compatible menu, etc
  - meta-gnustep package in Debian could 'recommends' this package so
that it remains optional
  - also configure a default awesome theme in a separate 'recommends'
package that both 'gnustep-session' and 'libgnustep-gui'  could use --
ship config files, depend on the theme we want to use, but don't
require install of this package

- Regular automated releases of binaries for distros we want to support
  - including tests covering whatever configuration combinations we
want to actively support (and someone actually paying attention to
that)
  - this is beyond just the great work done by packagers who interact
with us, like Debian ones do
  - I tried to give it a go a few years ago (see `make deb` and `make
debfiles` in gnustep-make) -- and I built packages using Canonical's
Ubuntu PPA builder -- but didn't fully set it up
    - this requires actual commitment to declaring "oh, PPA build
failed? this is critical and I will revert my change until it builds
green"
    - PPA builds should also be done only for proper releases, not on
every commit -- so one needs to implement the scaffolding for building
.debs in the same way PPA builder will do (and pay for the software
infra)

- A 'reference distro' mentioned elsewhere in the thread
  - figure out a distro's installer
  - build the .iso / USB image
  - ensure this is so reproducible automation can do it when we make a
major release of -make/-base/-gui/-back

- Integration with FreeDesktop.org specs
  - correctly and comprehensively reading XDG basedir spec is near the
top of this list
    - include transition code so Debian users who had their files
stored in ~/GNUstep don't get surprised at 'suddenly all my configs
are gone'
    - no, specifying the directories the way we do is not correct,
even if the resulting tree resembles out-of-the-box XDG experience
  - add a xdg .desktop parser to gworkspace, have a launcher for apps
that are not .app bundles AND .app bundles

- Themes must look great when used in other environments
  - ensure gtk and win32 themes are superb, always, no matter the
personal preference
  - this is in addition to having a great theme for the reference
environment package

- Integrating with (sigh) Wayland
  - I saw some recent PRs which I didn't get around to trying out. Someday!
  - potential: car IVFs; there's even an IVF-specific shell
    - no, I have no idea about regulations governing software put into cars
    - yes, I think manufacturers should ensure the bugs in IVF UI do
not interfere with safety features, anyway, but ...

- Integrating with dbusmenu out of the box
  - global menus are cool, Linux DEs do them (libdbusmenu), Apple does
it, we should do it as a first class citizen, too
    - well, second class: apps that put a random NSView in the menu
deserve all the pain they experience when it turns out we can't send
their NSView over the DBus IPCs
  - yes, we have some code for this

- Ensuring default stock installed GNUstep on distros uses a good
theme (gtk theme e.g.)

- A window manager that truly takes advantage of GS concepts
  - to my knowledge, no X11 spec is really aware of 'this file path is
opened in this window' -- how do you offer the magical NSDocument
experience if no WM can support it?

- Advocacy in other desktop environments to adopt ideas that work great in GS
  - can we have xdg-mime integration in other systems used to register
types based on app bundles?
  - can we have file manager developers understand bundles as
'documents', not just 'directories'? i.e. 'both dirs and files can be
documents, not just files'

- Least important: first class support for glowy, animated,
fading-in-and-out interfaces (e.g. completing Core Animation and the
AppKit integration)
  - I am still sometimes traumatized by innards of gnustep-gui hence
the 'this isn't that important' part
  - It might be almost easier to just throw away the DPS
implementation, rebuild NSView from scratch on CA and Opal, and
finally also implement CALayers in non-OpenGL terms, hence my "meh,
who cares" despite this being what got me to contribute to GS in the
first place