"If you want something done, do it yourself", as said one of the best sci-fi movie villains.
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.
yjftsjthsd-h 12 days ago [-]
> 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.
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.
pajko 12 days ago [-]
Qt is not just a GUI toolkit and it does not need X or any X libraries, works fine with a framebuffer.
amelius 12 days ago [-]
Qt is great for its painting operations alone.
01HNNWZ0MV43FF 11 days ago [-]
Hell it's one of the cleaner ways to do async networking in C++ alone
skywal_l 12 days ago [-]
> "If you want something done, do it yourself"
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.
amelius 12 days ago [-]
> And emphatically yes, I want scrollbars back where scrollbars are due. Aping Apple in this regard was a very unfortunate choice by GTK.
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.
rtpg 12 days ago [-]
every rant like this inevitably goes into Gnome/GTK world. I must insist how much "better" (for these kinds of people) the Qt/KDE world is! People who are so passionate about this stuff just don't give any credit to one side of the equation that has stuck to its guns in terms of making apps that still have a billion buttons with text labels on them.
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.
zombot 12 days ago [-]
> Confine yourself into the prison of someone else’s walled garden at no additional cost.
Objection, your honor: At great additional cost.
userbinator 12 days ago [-]
what really got to me was the insane amount of churn, forcing me to touch decades-old code once written and long forgotten
I know this is a Linux-centric article, but I think Win32 (+WINE) is really the answer to having a stable GUI API.
_factor 12 days ago [-]
HTML and CSS with a sprinkle of JS, combined with the hardened web standardization we see today paints a pretty clear picture.
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.
toast0 12 days ago [-]
I'd prefer XCB over Xlib, but while X may feel crufty today and maybe even more in 5 or 20 years... it will probably still run.
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.
o11c 12 days ago [-]
Yeah, XCB is a case where the new thing actually is a major improvement over the old. Nobody should be using Xlib by choice these days.
Cthulhu_ 12 days ago [-]
I've yet to see that proven though; alongside web technology based GUIs is also the concept of evergreen applications, that is, stuff that gets updated and kept up to date all the time, and force pushed to end users.
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)
userbinator 12 days ago [-]
The web stuff churns even more - a lot more.
duskwuff 12 days ago [-]
There's a lot of churn in what's used in green-field development, but browsers rarely drop support for old features, outside of extraordinary cases like the Flash plugin. Old web sites will usually work just fine in a modern browser.
pajko 12 days ago [-]
Regarding old features, Manifest V2 -> Manifest V3 was so painful to some that they dropped Chrome.
duskwuff 12 days ago [-]
I'm talking about compatibility for web content, not for browser extensions which are a more volatile environment.
eek2121 12 days ago [-]
Disagree. many old features have been dropped. The blink tag, for example.
VMG 12 days ago [-]
but rarely in a backwards incompatible way - browsers still render very old sites
Chris2048 12 days ago [-]
Surely that's a webpage, not a GUI?
encrypted_bird 12 days ago [-]
If the interface layer between a user and a webpage is graphical, then that website has a GUI.
Chris2048 12 days ago [-]
Then anything on a screen is a GUI, as is every website.
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.
bawolff 12 days ago [-]
If google docs doesn't count as a GUI then i dont know what does.
pmontra 12 days ago [-]
Every native toolkit has its own idiosyncrasies. Some are closer to the OS official look, which changes along the years, some are different. I'm for a relaxed definition: if it's graphical it's a GUI, if it's text it's a TUI. Then we have larger or smaller rendering libraries. The browser is a particularly large one but often it's got the advantage of automatic app updates.
jakelazaroff 12 days ago [-]
Is an interface within a web browser not purpose-built? I think of “GUI” in contrast to “CLI” — which, yes, is inclusive of almost everything you interact with on a computer, including websites.
boxed 12 days ago [-]
NeXTStep is still ahead of most modern GUI frameworks imo.
krige 12 days ago [-]
So's Win9X (which is really insulting come to think about it) and AmigaOS 2.X/3.X
It's less about the specific OS/GUI and more about the era I guess.
boxed 12 days ago [-]
Win9X isn't an API. Win32 was horrible last I worked with it professionally ~2010. I'm going it bet it's still just as bad because of backwards compatibility concerns.
nsm 12 days ago [-]
Racket is related to LISP and already has a mature GUI implementation that uses native widgets on Windows and MacOS, and on Linux goes to GTK3 or falls back to GTK2.
https://docs.racket-lang.org/gui/index.html
It is used to create their full featured teaching IDE.
It is worth looking at before re-inventing the stack.
jeffbee 12 days ago [-]
I don't see what is supposed to be the problem about an application that is written for GTK2 shipping GTK2. Why is that a fate worse than death? By what means is anyone being forced to "churn", adopting GTK3?
yjftsjthsd-h 12 days ago [-]
Targeting GTK2 is fine right up until distros drop it, which I'm pretty sure has already happened in some cases.
jabl 12 days ago [-]
So then you do what ardour did, bundle (a subset of) gtk2 with your app sources? Not necessarily worse, and certainly a lot less work, than writing your own GUI library from scratch, that you then have to bundle with your app anyway because it's an obscure library nobody else has ever heard of?
nine_k 12 days ago [-]
GTK API was very irksome for the author.
DeathArrow 12 days ago [-]
Programming GUI using existing frameworks like GTK, QT, Fltk, Avalonia and mainstream programming languages like C/C++, .NET, Java, Python, is hard, buggy and not future proof.
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.
01HNNWZ0MV43FF 11 days ago [-]
> As it turns out, a UI toolkit is, at least conceptually, not very complicated.
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
snvzz 12 days ago [-]
Good.
Let's hope it doesn't quickly die out, and it holds over time.
Tired of the ever-bloating yet popular TKs.
duskwuff 12 days ago [-]
Reality check: GTK 2.0 was released in 2002. At that time, most computers had under 1 GB of RAM, many were running 256-color displays at ~1024x768, and anti-aliasing was an exotic, showy feature which was rarely used on desktop systems. Hardware graphics acceleration was only used for 3D games, and support for it on Linux was extremely limited. Cross-platform compatibility for GTK wasn't even a consideration yet; it was targeted exclusively at X11 systems.
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.
o11c 12 days ago [-]
Everyone I know was using 24-bit color well before 2002, though 16-bit color made some applications work better (8-bit color would only happen temporarily, when running a very old application). My family shelled out the money for a 1280x1024 monitor though; take that!
eek2121 12 days ago [-]
Win32 says hi. I know a lot of folks here don't like Microsoft, but it is the one API that refuses to die.
jcelerier 12 days ago [-]
> 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.
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
adastra22 12 days ago [-]
Hardware graphics acceleration started on Unix and was largely used professionally.
duskwuff 12 days ago [-]
For applications which displayed 3D graphics, sure. But using graphics acceleration as a more general tool on the desktop took a while longer - the first, experimental window compositors for X11 showed up around 2006.
kalleboo 12 days ago [-]
> the first, experimental window compositors for X11 showed up around 2006
Although Apple already started using compositing in 2002 with Quartz Extreme in Mac OS X 10.2, which also had X11 support.
foobiekr 12 days ago [-]
Nextstep used compositing in the late 1980s.
lproven 12 days ago [-]
[[citation needed]]
NeXTstep used Display Postscript. AFAIK this has no concept of 3D acceleration or anything akin to it, and was almost entirely unaccelerated.
foobiekr 4 days ago [-]
compositing has nothing to do with 3d acceleration.
NeXT slabs and cubes did have a low-function blitter used to composite the main display.
foobiekr 3 days ago [-]
Edit: this was the Turbo units, which did have a bus-assisted block copy.
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).
nine_k 12 days ago [-]
I had access to a DEC Alpha desktop workstation with a hardware OpenGL and X accelerator. It was in 1995, before the first 3dfx Voodoo was even released.
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.
mrob 12 days ago [-]
And it's still better than GTK3 because you can run it on Xorg without it being capped at 60fps regardless of monitor refresh rate.
Zardoz84 12 days ago [-]
I have cards from the 90's that had 2d hardware acceleration
12 days ago [-]
adastra22 12 days ago [-]
[flagged]
yjftsjthsd-h 12 days ago [-]
Er, which part of their stack is "obscure"? Common Lisp, FFI, Cairo, OpenGL, X11; it would be hard to pick more well-trodden ground IMHO. (Well, okay, there are even more popular options than clisp, but it's still not obscure, just slightly less widely used than ex. C or Java.)
adastra22 12 days ago [-]
"slightly less widely used" is doing a lot of heavy lifting there. For all of it except FFI.
yjftsjthsd-h 12 days ago [-]
I said clisp was slightly less widely used, not any of the other parts. Again, what exactly in their stack do you think is obscure?
adastra22 11 days ago [-]
These days, for new software, even OpenGL is obscure. And it stands out as odd--Vulkan is essentially the Khronos-approved successor to OpenGL, which is/was an API so thoroughly removed from the modern GPU model that any program using it would be CPU or system memory bound on modern hardware.
12 days ago [-]
yohbho 12 days ago [-]
Nitpick: Units never belong in [].
It is [height] = cm. not height [cm].
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?
Rendered at 12:04:47 GMT+0000 (Coordinated Universal Time) with Vercel.
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.
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.
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.
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.
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)
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.
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.
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
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).
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.
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?