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

[Ola Fosheim Grøstad]

On Tuesday, 1 June 2021 at 20:56:05 UTC, someone wrote:
> 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.

Well, on a Mac I would just embed a WebView which already is 
ready in the OS UI framework. Electron allows you to execute 
native code I think ("Napi" or something?). A better approach is 
probably to use Chromium Embedded Framework v3, which supposedly 
is multithreaded.

> 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 ?

Not that much of a performance bottle neck, unless you push a lot 
of data. I wouldn't use it for an audio/graphics editor. Memory 
usage is more of an issue though. Depends on the app, if it is a 
"clock" then it obviously is too much. If it is a full 
application then it is ok.


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

Primarily because it cuts down on developer time. It is easy to 
change and you can easily configure it for many configurations 
(e.g. easy to create a limited features version).

This trend will increase as web component repos become available. 
At some point it might become prohibitively expensive to develop 
complex user interfaces without web technology.

Right now, drag-and-drop is not as easily supported in browser 
UIs though. That is an argument for using native UI.


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

The problem now is that you have to support both Metal, OpenGL 
ES, and Direct X. Vulkan isn't well enough supported to be a 
convenient target.

History also tells us that hardware GPU abstractions tend to be 
weak and not last very long.

So you are still stuck with an abstraction layer like Skia. It is 
just too expensive to support all hardware yourself.

The game industry spends a lot of money supporting/testing 
various hardware drivers and working around bugs in said 
drivers/hardware.

At the end of the day, the user will be upset if the application 
crashes because of a vulkan-bug/hardware-bug. So in that context 
browser-overhead isn't all that bad.


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


It is not so much that I disagree, but the hard reality is that 
there are few attractive alternatives that are portable and also 
cuts down on developer time.

I would personally consider the options:

1. Rolling my own using Skia, especially if I only need mouse 
input and no keyboard.

2. CEF or WebView, just to get to a productive stage sooner. 
Assuming the UI is not pushing a large amount of data.

3. Qt/Gtk, but I think they come with a lot of baggage... so I 
personally don't find it more attractive than WebView for basic 
UIs. If you already know webtech it becomes even less attractive 
to learn a framework that is less flexible than a webview. I 
don't see a healthy future for Qt/Gtk, but webtech is there to 
stay.

Note: Many simple GUI toolkits are horribly inefficient as they 
let each object render themselves.  An efficient GUI engine will 
have to replicate some of the browser complexity...