On Sun, Dec 19, 2021 at 3:48 PM Liam Proven <[email protected]> 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
