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 reply 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
parent Anton Pastukhov <mail anton9.com> writes:
On Saturday, 23 May 2026 at 20:04:25 UTC, just say no to phobos 
brainrot wrote:

 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


Hi Adam! Nice nickname
May 24
prev sibling parent reply 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
parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
On Sunday, 24 May 2026 at 01:16:43 UTC, c-smile wrote:

 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,


No, it is not. Here are some platforms where it is not available 
or is very hard to properly build and use:

- Secure Web Environments (where WebGL/WebGPU are blocked)
- visionOS (Apple Vision Pro)
- PlayStation 5 / Xbox Series consoles
- watchOS (Apple Watch)
- RTOS / Microcontrollers (FreeRTOS, Zephyr)

There are probably many more that I did not think of.

However, considering the limited scope of the DlangUI, skia could 
be a good choice.

D has good choices for GUI applications, one of them is giD: 
https://github.com/Kymorphia/gid . Some [really good 
applications](https://github.com/Kymorphia/gid#gid-applications) 
are made with it...
May 24
parent reply c-smile <andrew sciter.com> writes:
On Sunday, 24 May 2026 at 18:49:09 UTC, Dejan Lekic wrote:


 No, it is not. Here are some platforms where it is not 
 available or is very hard to properly build and use:

 - Secure Web Environments (where WebGL/WebGPU are blocked)


Not sure I understand how Skia is related to Web environments. 
And how is WebGL/WebGPU is related to it. AFAIR Skia may render 
on native WebGPU. But that just one of possible backends it 
supports. It can rasterize stuff on plain bitmap (CPU) and that's 
pretty secure.


 - visionOS (Apple Vision Pro)
 - PlayStation 5 / Xbox Series consoles
 - watchOS (Apple Watch)
 - RTOS / Microcontrollers (FreeRTOS, Zephyr)


In this discussion we are talking about desktop UI primarily. And 
these aren't them.
On such devices (IoT) there are other options, like NanoVG that 
is pretty adequate and small.


 However, considering the limited scope of the DlangUI, skia 
 could be a good choice.


It is a good choice for GPU accelerated rasterization.

But for UI it requires specific infrastructure: DOM, set of 
input/reusable widgets, event wiring, accessibility, layout 
managers, styling/branding... Many things to be short.


 D has good choices for GUI applications, one of them is giD: 
 https://github.com/Kymorphia/gid . Some [really good 
 applications](https://github.com/Kymorphia/gid#gid-applications) are made with
it...


giD is an option on very small (I would even say marginal) set of 
targets: only on Linux'es that run GTK based desktop managers. 
Like Ubuntu, but not Kubuntu, etc.

At the moment D has ABSOLUTELY no options for modern UI. On 
largest desktop platform (Windows) there is a semi-option to use 
Win32 API but most of MS apps are using now UWP/WinUI that D 
simply has no idea about.

Really, the only cross-platform and modern UI option now is my 
Sciter/D. Sciter is proven to handle UI since 2007 and on 460 mln 
machines (as UI layer of various apps).
May 24
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 24 May 2026 at 19:42:38 UTC, c-smile wrote:

 AFAIR Skia may render


I mostly reject talk about "rendering" when it comes to guis. I'm 
sure you know, but the drawing is ... maybe 5% of gui code. You 
don't need much capability to get the job done, whereas the 
little user interface details are what adds up (and can be a lot 
more code to handle the platform-specific details).


 At the moment D has ABSOLUTELY no options for modern UI.


How do you define "modern"? tbh the win32 programs hold up a lot 
better than most those newer messes.
May 24
parent reply c-smile <andrew sciter.com> writes:
On Sunday, 24 May 2026 at 19:58:54 UTC, Adam D. Ruppe wrote:

 At the moment D has ABSOLUTELY no options for modern UI.





 How do you define "modern"?


If not to dive into theological discussions then that's easy.

Just try to find job list for "Web frontend developer" and 
"Native UI developer".
I am getting 96% ratio for the first group. So we can assume that 
96% of modern UI/UX development happens on the Web (HTML/CSS/JS) 
these days. So Web UI is what most of users will expect and treat 
as modern.

One of UX guru told me that their app's core implementation 
stayed the same in 20 years, they just update UI styles each year 
as "users trust more to modern looking app".

And their number of sold instances ... I wish all of us such 
numbers.

Developers are quite egoistic in respect to UI. They think that 
their own UI preferences is exactly what the rest of Earth 
population would want and expect.
May 24
parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Sun, May 24, 2026 at 08:43:38PM +0000, c-smile via Digitalmars-d-announce
wrote:
[...]

 Developers are quite egoistic in respect to UI. They think that their own UI
 preferences is exactly what the rest of Earth population would want and
 expect.


[...]

Not me.  I prefer CLI over GUI any day, and I *know* the rest of the
world does NOT want this.  :-P


T

-- 
Кто везде - тот нигде.
May 24
next sibling parent reply matheus <matheus gmail.com> writes:
On Monday, 25 May 2026 at 00:53:55 UTC, H. S. Teoh wrote:

 On Sun, May 24, 2026 at 08:43:38PM +0000, c-smile via 
 Digitalmars-d-announce wrote: [...]

 Developers are quite egoistic in respect to UI. They think 
 that their own UI preferences is exactly what the rest of 
 Earth population would want and expect.


 [...]

 Not me.  I prefer CLI over GUI any day, and I *know* the rest 
 of the world does NOT want this.  :-P


 T


I prefer CLI as well for many reasons, and on thing that get my 
nerves is when an app has its layout changed, like when you see a 
tutorial and the version that you currently have is different and 
you can just follow it.

I even hate when OS do this, that's why terminal sometimes is so 
refreshing.

Another thing is taking you away from keyboard to go to mouse to 
click on something that doesn't have a shortcut. I friend of mine 
told me once that this something they do deliberated so their app 
is compatible or having the same behavior with touch screens / 
mobile etc.

Matheus.
May 25
parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Mon, May 25, 2026 at 10:06:16AM +0000, matheus via Digitalmars-d-announce
wrote:

 On Monday, 25 May 2026 at 00:53:55 UTC, H. S. Teoh wrote:


[...]

 Not me.  I prefer CLI over GUI any day, and I *know* the rest of the
 world does NOT want this.  :-P




[...]

 I prefer CLI as well for many reasons, and on thing that get my nerves
 is when an app has its layout changed, like when you see a tutorial
 and the version that you currently have is different and you can just
 follow it.
 
 I even hate when OS do this, that's why terminal sometimes is so
 refreshing.


See, I decided decades ago that I hate GUIs, and ever since then I've
forsaken the entire concept of the desktop metaphor.  My only OS UI
these days is the shell, and I've never looked back.



 Another thing is taking you away from keyboard to go to mouse to click
 on something that doesn't have a shortcut.


I installed Vim keybindings on my browser and generally avoid the rodent
like a plague except when there's no other choice.  I hate it when a
site requires mouse interaction to work. (Generally I'd just leave and
never come back to said site.)



 I friend of mine told me once that this something they do deliberated
 so their app is compatible or having the same behavior with touch
 screens / mobile etc.


[...]

IMAO, they got the whole touchscreen UI backwards.  Rather than
shoehorning "desktop" concepts onto a touchscreen, what they *should*
have done is to make use of the flexibility to make an
infinitely-customizable virtual keyboard that can dynamically change in
ways a physical keyboard never can, thereby allowing you infinite
expressibility far beyond what a desktop terminal UI can ever achieve.
Imagine a touchscreen virtual keyboard that lets you type D keywords
with a single touch, and contextually changes to allow 1- or 2-touch
identifier typing based on dynamic scanning of your code, that switches
to a traditional keyboard layout when you open a quoted string.  And
then with 1-touch escape sequences readily accessible based on the type
of string literal you're typing.  Think of the level of coding you could
achieve!

But nooo, to avoid alienating users we have to dumb down the interface
to the lousy old desktop metaphor, sigh.

//

See?  I *know* the rest of the world definitely does NOT want what I
prefer. :-D


T

-- 
Being forced to write comments actually improves code, because it is
easier to fix a crock than to explain it. -- G. Steele
May 25
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 25 May 2026 at 14:54:42 UTC, H. S. Teoh wrote:

 See, I decided decades ago that I hate GUIs
 [...]
 I installed Vim keybindings on my browser


vim is a (low res) gui application!

ed is the standard editor.
May 25
parent "H. S. Teoh" <hsteoh qfbox.info> writes:
On Mon, May 25, 2026 at 03:27:51PM +0000, Adam D. Ruppe via
Digitalmars-d-announce wrote:

 On Monday, 25 May 2026 at 14:54:42 UTC, H. S. Teoh wrote:

 See, I decided decades ago that I hate GUIs
 [...]
 I installed Vim keybindings on my browser


 
 vim is a (low res) gui application!
 
 ed is the standard editor.


And here I was thinking you were going to suggest an opened hard drive,
a magnet, and a very steady hand.

:-P


T

-- 
Many open minds should be closed for repairs. -- K5 user
May 25
prev sibling parent reply c-smile <andrew sciter.com> writes:
On Monday, 25 May 2026 at 00:53:55 UTC, H. S. Teoh wrote:


 I prefer CLI over GUI any day


Let me clarify this a bit: you prefer CLI in your area of 
expertise.

In areas where we are "seasoned users" we prefer GUI just to 
minimize efforts to perform actions. Like to make your TV louder 
you wouldn't go to terminal to send IR commands to it.

The thing is that we, human beings, are lazy. This goes back to 
the basics of thermodynamics so is unavoidable.

Most of GUI users are seasoned ones. They do not want to read 
manuals each year when they need to fill taxes online for 
example. First application that will have just one big green 
button "Fill those damned tax forms for me" will win, right?

Actually latest AI phenomenon is about our laziness too. We'd 
better create a machine that will read all those manuals at dusty 
bookshelves and ask us "do you want that green button pressed, 
yes/no?".

Really, laziness is the most significant driving force of 
technical progress.
May 25
parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Mon, May 25, 2026 at 04:54:54PM +0000, c-smile via Digitalmars-d-announce
wrote:

 On Monday, 25 May 2026 at 00:53:55 UTC, H. S. Teoh wrote:
 

 I prefer CLI over GUI any day


 
 Let me clarify this a bit: you prefer CLI in your area of expertise.
 
 In areas where we are "seasoned users" we prefer GUI just to minimize
 efforts to perform actions. Like to make your TV louder you wouldn't
 go to terminal to send IR commands to it.


I would write a 2-line bash script with a 2-letter name to do it.  Just
3 keystrokes.  Even better, bind it to a 2-key sequence in my window
manager, ratpoison, so I don't even have to stop what I'm doing.



 The thing is that we, human beings, are lazy. This goes back to the
 basics of thermodynamics so is unavoidable.


Being lazy does not automatically mean follow the latest trends. I
reject trends.  Deliberately.  It doesn't mean I have to "work harder".
On the contrary, I find most GUIs painfully inefficient; continually
moving your hand back and forth to/from the rodent, moving the cursor to
a specific location on the screen, left click, right click, more hand
movements, navigating inordinately deeply nested submenus, etc..  On CLI
my hands are always on the keyboard, and most commands are accessible in
just a few keystrokes (auto-completion is a thing, after all; we're no
longer in the 70's).  With the exception of specific tasks that actually
require a GUI, like tracing a complex curve or manipulating graphical
data, I can accomplish most things 2x-3x faster than on any GUI. And I
can express things far beyond what any GUI can express just with a few
keystrokes.  An equivalent GUI would require a ridiculously complex
layout and ridiculously deeply-nested unnavigable submenus.

See?  I told you nobody will agree with me.  Everyone wants their GUI
and eye candy, but my screen is literally the antithesis of this: just a
blank background 100% covered by a terminal with no deco, not a single
button in sight, not a single window.  (Well actually, the terminal *is*
a window, but with no borders at all. And there are no other "windows"
in sight.) This is my UI for everything I use the computer for.  And
yes, I'm well aware just about nobody does this (or at least nobody
sane), and nobody knows how to use such a UI.  And I'm perfectly fine
with that.



 Most of GUI users are seasoned ones. They do not want to read manuals
 each year when they need to fill taxes online for example. First
 application that will have just one big green button "Fill those
 damned tax forms for me" will win, right?


You're talking about catering to the masses, what "most people" prefer.
I have zero interest in that.  Different priorities.



 Actually latest AI phenomenon is about our laziness too. We'd better
 create a machine that will read all those manuals at dusty bookshelves
 and ask us "do you want that green button pressed, yes/no?".


I hate what passes for "AI" these days.  I can think very well on my
own, I don't need to delegate my thought process to the machine.  Tasks
that I *don't* want to think about, I write programs and scripts to do
for me.  Deterministic programs, that do exactly what they're told, no
more, no less, not some probabilistic second-guesser pretending to be a
human and doing things that cannot be reliably repeated and debugged.  I
rather read the manuals and write code to do exactly what I want, than
to let somebody (or something) else do the thinking for me and I just
push the big red button.  If all it takes is pushing a button, it's not
worth my time doing.  Let somebody else do it, thank you very much.  Or,
these days, let some LLM do it.  Whatever floats your boat.  I'll be
over here, with my blank screen and rodent-free UI that nobody else
knows how to operate, writing my bash scripts (or these days, D scripts
-- D is awesome for things like that, much cleaner language than the
pile of hacks which is bash scripting).  It's OK to be different,
y'know?



 Really, laziness is the most significant driving force of technical
 progress.


What you call progress, I call regression.  But again -- we have
different priorities.  That's why I said from the beginning: I *know*
that my preferences are definitely NOT what "everyone else" wants,
whoever "everyone else" may be.  (Insert cheesy quote here: "We are
not the same".  :-D)


T

-- 
Give me some fresh salted fish, please.
May 25
parent reply c-smile <andrew sciter.com> writes:
On Monday, 25 May 2026 at 18:01:22 UTC, H. S. Teoh wrote:

 I would write a 2-line bash script with a 2-letter name to do 
 it.


So, did you do it?

Aside: D programmers are so strong that they switch gears using 
strictly two-letters scripts. And their RAM is so large that they 
remember all 676 of such scripts. And all their arguments.
May 25
parent "H. S. Teoh" <hsteoh qfbox.info> writes:
On Mon, May 25, 2026 at 06:51:40PM +0000, c-smile via Digitalmars-d-announce
wrote:

 On Monday, 25 May 2026 at 18:01:22 UTC, H. S. Teoh wrote:

 I would write a 2-line bash script with a 2-letter name to do it.


 
 So, did you do it?


I bound a 2-keystroke sequence to the volume controls.  That enough for
you?



 Aside: D programmers are so strong that they switch gears using
 strictly two-letters scripts. And their RAM is so large that they
 remember all 676 of such scripts. And all their arguments.


[...]

I don't know why you're arguing about this.  I said repeatedly, my
preferences are simply that: MY preferences.  Not yours, not anyone
else's.  I KNOW that my preferences do not reflect anyone else's. (Well
OK, *maybe* somewhere out there is another maniac like myself who shares
the same preferences. But that's beside the point.)  I'm not asking
anyone to change their preferences, I'm merely stating my own.  Why are
we even arguing about this? lol


T

-- 
Last night, I dreamed about my pet rabbits all lined up like in a parade, and
hopping backwards.  Then I woke up and realized that it was my receding hare
line!
May 25
prev sibling next sibling parent Dejan Lekic <dejan.lekic gmail.com> writes:
On Sunday, 24 May 2026 at 19:42:38 UTC, c-smile wrote:

 giD is an option on very small (I would even say marginal) set 
 of targets: only on Linux'es that run GTK based desktop 
 managers. Like Ubuntu, but not Kubuntu, etc.


I am curious how did you come by this conclusion? (Please start a 
new thread for this, if you want to continue the discussion as 
this is off-topic)

GTK, just like QT (core part of the KDE ecosystem), works on 
_any_ Linux, _any_ Windows, and _any_ MacOS. giD ofc offers more 
than just GTK, but that is off-topic here... They BOTH work on 
Kubuntu, just like any KDE application works on a GNOME-based 
desktop!

Anyway, I propose we stop here as I do not want this thread, 
which is about DlangUI, to become a thread about giD, 
sciter/skia, etc...
May 25
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 24 May 2026 at 19:42:38 UTC, c-smile wrote:

 Really, the only cross-platform and modern UI option now is my 
 Sciter/D.


```diff
diff --git a/sciter+/D/sciter/types.d b/sciter+/D/sciter/types.d
index ae0695b..c8ee986 100644
--- a/sciter+/D/sciter/types.d
+++ b/sciter+/D/sciter/types.d
   -1,3 +1,4   
+module sciter.types;

  alias INT_PTR = ptrdiff_t;
  alias UINT_PTR = size_t;
diff --git a/sciter+/D/sciter/utils/archive.d 
b/sciter+/D/sciter/utils/archive.dindex 2f46229..e98dfe9 100644
--- a/sciter+/D/sciter/utils/archive.d
+++ b/sciter+/D/sciter/utils/archive.d
   -1,4 +1,4   
-module sciter.util.archive;
+module sciter.utils.archive;

  import sciter.api;
  import std.string;
```

to make it up to spec, rn it only compiles due to some compilers 
not checking names.
May 25
parent c-smile <andrew sciter.com> writes:
On Monday, 25 May 2026 at 17:33:58 UTC, Adam D. Ruppe wrote:


 diff


Oh, thanks a lot.
May 25