wanting to try a GUI toolkit: needing some advice on which one to choose

[someone]

On Tuesday, 1 June 2021 at 16:20:19 UTC, Ola Fosheim Grøstad 
wrote:

> I don't really agree with this, most of the interesting things 
> for specifying UIs are happening in in 
> web-frameworks/web-standards nowadays.

I wasn't considering/referring to content in the browser, this is 
an entirely different arena.

> If I were to make a desktop application in D today then I would 
> have chosen to either embed a browser-view and use that for 
> interface, or electron. Not sure if has been mentioned already, 
> but it is an option.

I don't agree with that at all but I respect your point and 
encourage you to do so provided you'll end with something useful 
to you.

The point with that approach is performance, performance, and did 
I say it ? ... performance.

I don't know about you but, what are the reasons you choose to 
develop in D ? One of the often cited reasons I came across is 
performance alongside with better-C style comments and full OOP 
and the like; which as a side-note it happens to be my case. So 
for a little while put you on my shoes and try to see the subject 
we are discussing from my point of view:

Now think for a instant, that you choose D for performance so you 
expect it to be fast, and you write the hello world app to begin 
with, and you fire-up a full-framework like Electron or the like 
just to give you basic GUI controls. Stretch it a bit, instead of 
using Electron and family you coded a basic HTML page saying 
hello world and put a button in a form element to close the 
page/document and then you embed a web browser within your app, a 
fully-fucking-huge-meaning-millions-of-lines-of-code-with-thousands-of-non-relevant-modules-like-TLS/SSL-Web-Assembly-JavaScript-and-keep-counting just to ... render hello world inside your blazingly-fast-lean D program ?

Will it work ?

Sure.

But, why are we, to begin with, stacking layers upon layers of 
APIs (meaning millions of lines of code and/or degrading 
performance to extreme levels and/or increasing the attack 
surface of our lean app) just to say hello world in a window and 
expecting the user to close it at any given time and ... nothing 
more ?

Why did we choose to use huge frameworks, embed browsers, etc to 
write a simple app ?

Because the basics, the foundations, are broken.

Instead of trying to fix the broken bits to allow us to choose 
the obvious/correct/lean/straightforward path, we, developers 
(and now I am talking from the point of view of the whole 
community), keep using higher and higher levels of abstraction to 
accomplish simple things.

Given the power of a typical computer nowadays there is no excuse 
for a GUI to be blazingly-fast, snappy-as-hell, zero-lag. If 
these symptoms are present we are doing it wrong.

Don't get me wrong: browsers are extremely useful pieces of 
software. The problem is everybody starts to think the browser is 
the OS. This approach, to my humble point of view, is 
short-sighted. We came full-circle: from everything done on the 
mainframe with stupid terminals on the other side of the line, to 
personal computers offloading work from servers and starting 
"thinking" by themselves and all the related client/server stuff 
of the early 90s, to the Sun's vision the-network-is-the-computer 
and all the related Java stuff which more-or-less brought us the 
web browsers, to the google's vision the-web-browser-is-the-OS 
approach. Endless layers upon layers. Web browsers are fantastic 
for browsing/reading complex documents with all its hyperlinks, 
stupid things that now assume for granted, but with its complex 
rendering engines, they are, and I said it once again, fantastic 
pieces of software. The problem with the web browser, and now we 
are backing to the GUI subject we are discussing here, is that 
sometimes in mid-00s their development started to be orchestrated 
by the commercial world and specifically by the ad industry, 
seeing them as software to sell relegating its primary purpose of 
knowledge/browsing documents, that's why we left HTML 4/XHTML 
1.0/1.1 behind and got HTML 5 instead of XHMTL 2 which was the 
right way to go if the browsers kept sticking to their primary 
goal. Now the browser mandates font face/style/size, 
strict-layouts, a magazine, a cool selling magazine on my screen. 
Evolution. Nothing against it, quite the opposite, a 
document-centric and app-centric browser split was what was 
needed then. Dreams. So from then on we started to see the 
decadence of GUI design: buttons that didn't look like buttons at 
all, etc. Which is that ? Ah, dunno, try to click over it and 
let's check if anything happens ... are you following me ? Then 
came Johnny Ives @ Apple with its concept of the flat user 
interface. Now everything is flat: is this a button ? is this a 
... ? Who knows. This was followed by everyone outside Apple 
since Apple was cool back then, and we got gnome 3 and KDE Plasma 
and Unity. Everything learned so far went to the trashcan. So 
real people doing real work reacted a bit and we got MATE and the 
like, but it was the timeframe of the desktop being displaced by 
the smartphones and/or tables for moma/popa/and-the-likes and the 
power user now became a niche nobody cared for, very reasonable, 
the real money was not there. Transparent windows ! Why on Earth 
would you want a transparent window ? Do you think taking notes 
back then at college on a transparent or semi-transparent notepad 
would make sense ?

Summarizing a bit: GUIs were oversimplified over time to account 
for the non-tech-savvy users which happened to be the great 
majority of them with the advent of mobile devices, and, instead 
of splitting things apart the GUI was dumbed to extreme levels to 
accommodate such users, the less-common-denominator ... this is 
the problem with GUI design guidelines nowadays. The GUI toolkits 
exploded in complexity to support mobile and every-corner-case 
possible and became very difficult to maintain and that's why I 
think many toolkits stalled. I think someone with the knowledge 
to write a classical toolkit in pure-D following the classical 
design principles with the standard controls and nothing more 
should need deep openGL knowledge to begin with (however a better 
choice should be start from zero with its Vulkan successor) 
providing he/she has access to proven code for text input and/or 
font rendering (quite complex) and besides full-UniCode support 
(which in D is not a problem at all).

This is my two cents.

And of course, feel free to argue on everything you disagree with 
:)