On Friday, 22 May 2026 at 17:20:21 UTC, Anton Pastukhov wrote:
I have a fork of DlangUI.
Some thoughts on D/UI efforts.
First and foremost, D is nearly ideal language for UI frameworks,
yes. So I understand why ["Уж сколько их упало в эту бездну" /
"Oh, how many of them fell into this
abyss"](https://ruverses.com/marina-tsvetaeva/how-many-has-this-chasm-already-swallowed/7085/), myself is included :)
### Text Layout
Big part of UI is correct text rendering. That means support of
not just LTR but RTL and ideally TTB text layouts. DLangUI lacks
this as far as I can see in its codebase. Emojis rendering is
part of this too (what is the modern UI without those grim faces?)
1. To properly handle those, UI framework should use HarfBuzz
(glyphs composition), libgrapheme (text reordering), UNICODE
symbol classifications (icu4c?) and/or the like.
2. Otherwise the framework shall operate by more high level
constructs like IDWriteTextLayout, Pango, CoreText, etc. Those
allow to deal with text rendering and measurement in a box
without diving onto separate glyphs level (that is the abyss,
indeed). But those text layout frameworks are closely tied with
particular graphics stacks and usually cover just basic layouts
(text-in-a-box, but not text-inside-arbitrary-shape).
### Windowing Backends
SDL, GLFW and Co. are mostly about basic window creation and
support of so called "message pumps" - waiting for physical
events from input devices (e.g. MOUSE_DOWN) and
dispatching/transforming them into logical events (CLICK,
DBLCLICK, etc.).
But there are quite many desktop UI events and features that are
coming from window managers and UI subsystems that are not that
trivial. Standard dialogs, native window styles, drag-n-drop,
gesture handling. Think about animated touchpad scroll for
example (good luck to implement that with SDL on major desktop
OSes).
I am pretty confident that Window and Application abstractions
should end up using more high-level (than SDL) API levels. On
Windows and MacOSX there are no other options as their native API
(HWND, NSWindow) and that is sufficient.
But on Linux, on that "UI Zoo", we should ideally cover more
options: window and application management should use GTK/Gnome,
KDE/Plasma, etc. Only those provide proper desktop integration
facilities and events. Use of naked X11 and Wayland API should be
left as a last resort only.
### General thoughts
"Ложка дорога к обеду" / "Price of spoon is higher when time is
closer to dinner".
I mean that time for pure D UI was gone 10 years or so ago. It
could be D at Mozilla but not that esoteric Rust. My educated
guess is that Rust was born in understanding that development in
large and distributed community required better (more strict and
robust in many senses) language. So they are trying to do the
whole thing in Rust now. Instead of D, sigh.
So the practical option now is, I think, to decompose universal
application framework into UI layer and the rest (a.k.a. BLL -
business logic layer).
Brute reality says that UI layer shall be made in C/C++ so it can
be shared (and effort paid off considering #1 and #2) with other
languages.
At the end UIL and BLL use quite different code flows, ownership
graphs and life cycles so such split is natural and allows to get
the best of two worlds.
My pardon if for someone all this may sound as a demotivator but
this was not my intent.
