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

someone someone at somewhere.com
Tue Jun 1 22:50:49 UTC 2021


On Tuesday, 1 June 2021 at 21:47:38 UTC, Ola Fosheim Grøstad 
wrote:
> Well, on a Mac I would just embed a WebView which already is 
> ready in the OS UI framework.

Thanks for the illustration on how you'll eventually proceed with 
it on the Mac side of things -I use iPhones since the 4 series 
but frankly I never developed on (or used for a significant time) 
a modern Mac.

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

It just came to mind the first time I installed and used a linux 
distro for a significant amount of time: it was Ubuntu in the 8~9 
time-frame circa 2008~2009 (Jaunty Jackalope if memory serves), 
and coming from the Windows world, mainly on the Windows server 
platform which we usually (and thoroughly) optimized as 
workstations for our daily drivers (we can't even stood for a 
minute the amount of crap Microsoft dumped on its consumers OSs 
-even configuring them with the classical UI dumping animations 
and a zillion more things), the first thing I noticed and struck 
me was the responsiveness of the GUI: snappy as hell compared to 
the usual Windows 7 machines we dealt with at the time, and, I 
mean snappy as hell **without** customizing it disabling 
animations and the like, this was a responsive GUI 
out-of-the-box. It was on gnome 2 of course. The first time I saw 
gnome 3 was game over.

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

If we were on slashdot I would undoubtedly mark this as 
insightful.

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

IIRC openGL ES is for mobile not for desktop which needs plain 
openGL.

Of course individually supporting the three main APIs is a no-go, 
that's why I mentioned Vulkan, you say it is not mature, it will 
mature. To me Vulkan is like Wayland, there's no going back 
regardless whether you/we consider it has merits or not.

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

Indeed. But the market is so huge nowadays that the stakes are 
set higher. Or so I want to believe.

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

Indeed. But the game industry has totally different 
requirements/expectations for the hardware than we need to write 
a classical 2D GUI toolkit. They need APIs close to the hardware 
as possible and very often bypass everything in its path seeking 
3D performance gains.

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

I guess Vulkan will have separate 2D/3D APIs like openGL so this 
will be no major concern giving the huge different code base size 
for each, but I am talking of pure guess, I will eventually read 
about it (at least) out of sheer curiosity.

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

Sad by true.


More information about the Digitalmars-d-learn mailing list