[HN Gopher] The Barium Experiment
___________________________________________________________________
The Barium Experiment
Author : todsacerdoti
Score : 75 points
Date : 2025-04-09 00:44 UTC (22 hours ago)
(HTM) web link (tomscii.sig7.se)
(TXT) w3m dump (tomscii.sig7.se)
| userbinator wrote:
| _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 wrote:
| 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.
| Chris2048 wrote:
| Surely that's a webpage, not a GUI?
| encrypted_bird wrote:
| If the interface layer between a user and a webpage is
| graphical, then that website has a GUI.
| Chris2048 wrote:
| 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.
| jakelazaroff wrote:
| 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.
| bawolff wrote:
| If google docs doesn't count as a GUI then i dont know
| what does.
| pmontra wrote:
| 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.
| userbinator wrote:
| The web stuff churns even more - a lot more.
| duskwuff wrote:
| 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.
| eek2121 wrote:
| Disagree. many old features have been dropped. The blink
| tag, for example.
| pajko wrote:
| Regarding old features, Manifest V2 -> Manifest V3 was so
| painful to some that they dropped Chrome.
| duskwuff wrote:
| I'm talking about compatibility for web content, not for
| browser extensions which are a more volatile environment.
| VMG wrote:
| but rarely in a backwards incompatible way - browsers still
| render very old sites
| toast0 wrote:
| 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 wrote:
| 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_ wrote:
| 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)
| duskwuff wrote:
| 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.
| adastra22 wrote:
| Hardware graphics acceleration started on Unix and was largely
| used professionally.
| nine_k wrote:
| 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.
| duskwuff wrote:
| 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 wrote:
| > _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 wrote:
| Nextstep used compositing in the late 1980s.
| lproven wrote:
| [[citation needed]]
|
| NeXTstep used Display Postscript. AFAIK this has no
| concept of 3D acceleration or anything akin to it, and
| was almost entirely unaccelerated.
| o11c wrote:
| 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 wrote:
| Win32 says hi. I know a lot of folks here don't like Microsoft,
| but it is the one API that refuses to die.
| Zardoz84 wrote:
| I have cards from the 90's that had 2d hardware acceleration
| mrob wrote:
| 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.
| jcelerier wrote:
| > 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
| snvzz wrote:
| Good.
|
| Let's hope it doesn't quickly die out, and it holds over time.
|
| Tired of the ever-bloating yet popular TKs.
| nine_k wrote:
| "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 wrote:
| > 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 wrote:
| Qt is not just a GUI toolkit and it does not need X or any X
| libraries, works fine with a framebuffer.
| amelius wrote:
| Qt is great for its painting operations alone.
| amelius wrote:
| > 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.
| skywal_l wrote:
| > "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.
| jeffbee wrote:
| 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 wrote:
| Targeting GTK2 is fine right up until distros drop it, which
| I'm pretty sure has already happened in some cases.
| jabl wrote:
| 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 wrote:
| GTK API was very irksome for the author.
| rtpg wrote:
| 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.
| DeathArrow wrote:
| 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.
| boxed wrote:
| NeXTStep is still ahead of most modern GUI frameworks imo.
| krige wrote:
| 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 wrote:
| 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.
| zombot wrote:
| > Confine yourself into the prison of someone else's walled
| garden at no additional cost.
|
| Objection, your honor: At great additional cost.
| yohbho wrote:
| 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?
| nsm wrote:
| 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.
___________________________________________________________________
(page generated 2025-04-09 23:02 UTC)