www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Dcanvas, a fork of DlangUI

reply Anton Pastukhov <mail anton9.com> writes:
Hi everyone!

I have a fork of DlangUI.
Code: https://gitlab.com/anton999/dcanvas
TLDR and rationale: https://anton9.com/articles/dcanvas.html

Happy to answer questions, if you have any.
May 22
next sibling parent reply Sergey <kornburn yandex.ru> writes:
On Friday, 22 May 2026 at 17:20:21 UTC, Anton Pastukhov wrote:

 Hi everyone!
 Happy to answer questions, if you have any.


Privet Anton!
Looks cool. Hope you will succeed with support

I've tried helloworld example - works on macOS

Do you have plans for SDL3 migration in future?
May 23
parent Anton Pastukhov <mail anton9.com> writes:
On Saturday, 23 May 2026 at 11:25:17 UTC, Sergey wrote:

 On Friday, 22 May 2026 at 17:20:21 UTC, Anton Pastukhov wrote:

 Hi everyone!
 Happy to answer questions, if you have any.


 Privet Anton!
 Looks cool. Hope you will succeed with support

 I've tried helloworld example - works on macOS

 Do you have plans for SDL3 migration in future?


I do, and I explored this option briefly. SDL3 have some 
niceties, such as native file dialog windows and better hardware 
acceleration. That said, for 1.x we're probably stuck with SDL2. 
Currently it's antiquated SDL 2.0.4, which I plan to update to 
the latest 2.x soon
May 23
prev sibling parent reply c-smile <andrew sciter.com> writes:
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-alrea
y-swallowed/7085/), myself is included :)



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).



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.



"Ложка дорога к обеду" / "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 

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.
May 23
parent reply Anton Pastukhov <mail anton9.com> writes:
On Saturday, 23 May 2026 at 16:35:28 UTC, c-smile wrote:

c-smile thanks for the thoughtful answer!




 Big part of UI is correct text rendering.


Absolutely, and the current state of affairs in DlangUI/Dcanvas 
is meh. Before we talk about niceties like emoji rendering, I 
have to do some basic performance optimizations, becuase the 
current implementation is _terribly_ ineffective (EditBox widget 
chokes on less-than-medium-sized texts). [Text editing hates 
me](https://faultlore.com/blah/text-hates-you/) and [text 
rendering hates me 
too](https://lord.io/text-editing-hates-you-too/) and I'm aware 
of that.


SDL, GLFW and Co. are mostly about basic window creation and 
support of so called "message pumps"


This is basically what we do now. SDL creates windows, but 
doesn't do much afterwards. I have high hopes about SLD3 though.


I mean that time for pure D UI was gone 10 years or so ago.
My pardon if for someone all this may sound as a demotivator but 
this was not my intent.


I'm well aware of that fact. I have had many different emotions 
about that, and currently I'm at the stage of acceptance. On the 
other hand, since this ship has sailed long time ago, no reason 
to hurry anymore.
May 23
parent reply c-smile <andrew sciter.com> writes:
On Saturday, 23 May 2026 at 17:04:16 UTC, Anton Pastukhov wrote:

 On Saturday, 23 May 2026 at 16:35:28 UTC, c-smile wrote:



 have to do some basic performance optimizations, becuase the 
 current implementation is _terribly_ ineffective (EditBox 
 widget chokes on less-than-medium-sized texts).


Naïve EditBox implementations have `O(N)` complexity on single 
character handling so no matter what you do it will be 
ineffective. On each character pressed it rescans (word/line 
breaking, etc.) of whole text.

That's why Sciter has three different text editors:

* `<textarea>` - standard for HTML multiline editor, ~1k chars.
* `<plaintext>` - Sciter specific multiline editor, 1mb chars. 
Text is represented in paragraphs (DOM element holding text line) 
so editing one paragraph is not causing re-layout of the whole.
* `<richtext>` - WYSIWYG editor that allow to edit HTML.

Sample of `<plaintext>` with support of colorizer/syntax 
highlighting:

![plaintext 
editor](https://sciter.com/wp-content/uploads/2026/05/plaintext-colorizer.jpg)


SDL, GLFW and Co. are mostly about basic window creation and 
support of so called "message pumps"


 This is basically what we do now. SDL creates windows, but 
 doesn't do much afterwards. I have high hopes about SLD3 though.


I would rather go with Skia from ground up. No SDL I mean. I've 
convinced once SDL people to implement rich clipboard support 
(they did in SDL3). Not just plain text but HTML, file lists, 
images, etc. But drag-n-drop is still basic AFAIK.

It has:

* [Window 
abstraction](https://github.com/google/skia/tree/main/tools/window)
implementation. It is a bit simplistic but as a base for future expansions will
work.
* GPU accelerated 2D graphics (DirectX, Metal, OpenGL, Vulkan).
* 
[SkParagraph](https://github.com/google/skia/tree/main/modules/skparagraph)
text container with styled text. A la `<p>` in HTML.
* 
[SkPlainTextEditor](https://github.com/google/skia/tree/main/modules/skplaintexteditor)

The only problem with Skia is that its C++ interface is unstable, 
so some isolation API layer is required in order to be used in D. 
Essentially same thing as [Sciter/D 
Graphics](https://gitlab.com/sciter-engine/sciter-js-sdk/-/tree/main/sciter%2B/D/sciter/graphics?ref_type=heads),
May 23
parent reply Anton Pastukhov <mail anton9.com> writes:
On Saturday, 23 May 2026 at 18:29:20 UTC, c-smile wrote:

 On Saturday, 23 May 2026 at 17:04:16 UTC, Anton Pastukhov wrote:

 On Saturday, 23 May 2026 at 16:35:28 UTC, c-smile wrote:



 have to do some basic performance optimizations, becuase the 
 current implementation is _terribly_ ineffective (EditBox 
 widget chokes on less-than-medium-sized texts).


 Naïve EditBox implementations have `O(N)` complexity on single 
 character handling so no matter what you do it will be 
 ineffective. On each character pressed it rescans (word/line 
 breaking, etc.) of whole text.


That's precisely what we have now, unfortuantely. I already 
realized that we'll need more edit widget sorts. The current 
EditBox is a bit of a god object and tries to bee everything at 
once (as many other things in the codebase).



 I would rather go with Skia from ground up.


Never heard of it, will take a look. SDL has an advantage of 
being C lib, and D's story of C interop is pretty strong. Not 
sure about C++.
May 23
next sibling parent just say no to phobos brainrot <confidential example.com> writes:
On Saturday, 23 May 2026 at 19:51:04 UTC, Anton Pastukhov wrote:

 That's precisely what we have now, unfortuantely. I already 
 realized that we'll need more edit widget sorts.


It took me years to get minigui's edit widget to the point where 
i didn't consider it an embarassment and it still isn't 
especially great...

meanwhile on Windows, I just did CreateWindow("EDIT", ...) and 
found joy lol
May 23
prev sibling parent c-smile <andrew sciter.com> writes:
On Saturday, 23 May 2026 at 19:51:04 UTC, Anton Pastukhov wrote:

 I would rather go with Skia from ground up.


 Never heard of it, will take a look.


Umm... Skia is everywhere these days : Google's Android, Chrome, 
Flutter and Fuchsia,
Mono/SkiaSharp, ReactNative, etc.

My Sciter uses Skia on all platforms. Only on Windows it may use 
Direct2D.


 SDL has an advantage of being C lib, and D's story of C interop 
 is pretty strong. Not sure about C++.


Well, who really cares about particular language if D can link 
static libs?

As I said the only thing you need is stable plain C API to the 
library (C file) and
```
#pragma comment(lib, "skia.lib")
```
in it.
May 23