Dcanvas, a fork of DlangUI

[c-smile]

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.