"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.
> 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.
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.
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.
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)
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.
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.
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.
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.
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.
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.
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?
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?
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.
> 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
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.
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.
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!
> 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.
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.
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.
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.)
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.
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?
"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.
> 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.
Qt is not just a GUI toolkit and it does not need X or any X libraries, works fine with a framebuffer.
Qt is great for its painting operations alone.
Hell it's one of the cleaner ways to do async networking in C++ alone
> "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.
> 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.
> Confine yourself into the prison of someone else’s walled garden at no additional cost.
Objection, your honor: At great additional cost.
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.
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.
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.
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)
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.
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.
The web stuff churns even more - a lot more.
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.
Regarding old features, Manifest V2 -> Manifest V3 was so painful to some that they dropped Chrome.
I'm talking about compatibility for web content, not for browser extensions which are a more volatile environment.
Disagree. many old features have been dropped. The blink tag, for example.
but rarely in a backwards incompatible way - browsers still render very old sites
Surely that's a webpage, not a GUI?
If the interface layer between a user and a webpage is graphical, then that website has a GUI.
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.
If google docs doesn't count as a GUI then i dont know what does.
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.
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.
NeXTStep is still ahead of most modern GUI frameworks imo.
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.
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.
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?
Targeting GTK2 is fine right up until distros drop it, which I'm pretty sure has already happened in some cases.
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?
GTK API was very irksome for the author.
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.
> 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
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.
Good.
Let's hope it doesn't quickly die out, and it holds over time.
Tired of the ever-bloating yet popular TKs.
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.
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!
Win32 says hi. I know a lot of folks here don't like Microsoft, but it is the one API that refuses to die.
> 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
Hardware graphics acceleration started on Unix and was largely used professionally.
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.
> 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.
Nextstep used compositing in the late 1980s.
[[citation needed]]
NeXTstep used Display Postscript. AFAIK this has no concept of 3D acceleration or anything akin to it, and was almost entirely unaccelerated.
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.
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.
I have cards from the 90's that had 2d hardware acceleration
[flagged]
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.)
"slightly less widely used" is doing a lot of heavy lifting there. For all of it except FFI.
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?
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.
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?