The Barium Experiment
tomscii.sig7.se
tomscii.sig7.se
A GUI toolkit that does not burden itself with compatibility with anything but X (working directly with Xlib) is already much leaner than GTK or Qt. The use of Common Lisp instead of C, Vala, or even C++ makes the problem even easier to tackle. No wonder Barium ended up being so compact, while doing everything a simple but complete toolkit needs to do.
It may even age gracefully, as the author wants it to, provided that Xlib stays around. Or maybe it could eventually develop a thin abstraction layer to allow pluggable rectangle-drawing and text-rendering APIs, and start supporting Wayland, too.
And emphatically yes, I want scrollbars back where scrollbars are due. Aping Apple in this regard was a very unfortunate choice by GTK.
For application software (which appears to be what the author cares about), xwayland (and the other one whose name escapes me at the moment[0]) should be a trivial way to support wayland perfectly well without actually having to expend any effort.
[0] EDIT: Found it; https://github.com/Supreeeme/xwayland-satellite ... which actually apparently is xwayland, just without needing compositor support. Not quite what I thought I remembered, still super cool and useful.
Apple is not as great in UI as most people seem to think. But I must say that I don't miss scrollbars on my phone.
That's how Sublime Text does it and it works great. Same UI on all platform, pretty fast and they control their destiny. Moreover, the ST binary will probably continue to work for the foreseeable future whatever the platform.
Seriously, if you find yourself annoyed at Gnome, you can set up KDE and (mostly) have no issues.
I say all this... Qt is a tricky beast to use. I prefer it to GTK but it's chunky.
Objection, your honor: At great additional cost.
I know this is a Linux-centric article, but I think Win32 (+WINE) is really the answer to having a stable GUI API.
JavaScript is here to stay, web browsers are here to stay, they can make GUIs that are durable.
I find it comical that X was the chosen target in this article, as it will most certainly be more than crufty in 5, let alone 20 years from now.
Yet, most would consider the term to refer to purpose-build interfaces, rather than those build upon the 'GUI' of a web-browser - which has it's own idiosyncrasies.
If you integrate with an html+js viewer, do you link it into your binary? If so, what are its dependencies and will they be around? If not, will you still be able to use the same viewer in 5-20 years or will it have some breaking change that requires additional work?
Worst case, you run VcXsrv in Wine, because win32+wine is the future proof platform; but if we're all running Wayland then, Xwayland should work, and I'd bet money if there's a replacement for Wayland in the next 5-20 years, it will have an available X server even if it can't integrate with Wayland clients.
And while on paper a web application built 20 years ago still works today as it was, the same can't be said about the technology used to develop and build these; there's a ridiculous amount of churn in the libraries and frameworks, to the point where you have to set up your github actions or whatever to frequently keep your stuff up to date, because if you run more than six months behind, any updates will break your carefully balanced setup.
Of course, that's a choice. Ultimately there's no real need to use Typescript, a framework, or a collection of libraries, and if you do choose them, there's the huge complex but fragile ones like Angular and React and their ecosystems, or smaller ones leveraging modern web tech developments or solving only a single problem. (I'm aware React was intended that way originally but in practice it's a whole ecosystem you're pulling into your application)
It is used to create their full featured teaching IDE.
It is worth looking at before re-inventing the stack.
So a guy writes his own toolkit using Common Lisp.
It would made more sense if he just wanted to experiment, learn or have fun.
Hee hee
Interesting read but as a seasoned Blub programmer I probably won't be binding my non-LISP code to Barium any time soon. This does give me ideas for *my* eventual GUI framework ofc
Let's hope it doesn't quickly die out, and it holds over time.
Tired of the ever-bloating yet popular TKs.
Which is a lot of words to say: software changes. The Linux desktop is a moving target; expecting a user interface library to hold still for 20+ years is a tall order.
I bet high-end Unix graphics workstations (CAD, video processing, etc) had it many years before that. The first graphics accelerator was offered by Silicon Graphics in 1983, yes, forty two years ago. It was supported by IRIX, a Unix variant.
Although Apple already started using compositing in 2002 with Quartz Extreme in Mac OS X 10.2, which also had X11 support.
NeXTstep used Display Postscript. AFAIK this has no concept of 3D acceleration or anything akin to it, and was almost entirely unaccelerated.
NeXT slabs and cubes did have a low-function blitter used to composite the main display.
Before that, just well-tuned 68030 burst block copy - they rendered to backing store and did block copies with a special case of vram to vram block copies (used for window compositing).
What do you understand by "display compositing" that doesn't involve 3D hardware?
Qt pretty much holds without major drastic changes to the approach since 1995. https://web.archive.org/web/20201109041256/https://www.qt.io...
We're at Qt 6.9 now and the process is still easy - there were only very few breakages between Qt 5 and Qt 6
Graphs are labeled wrongly in 8 out of 10 academic papers, too. First semesters learn this rule and forget it by third semester since it looks cooler. And height/cm as label seemingly does not?