"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'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.
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)
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.
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.
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?
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.
> 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
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.
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).
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?
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.