Ideal D GUI Toolkit

[Nick Sabalausky]

On Mon, 20 May 2013 23:47:47 +0200
Andrej Mitrovic <andrej.mitrovich at gmail.com> wrote:

> On 5/20/13, Adam Wilson <flyboynw at gmail.com> wrote:
> > * There is a deep-seated distrust of any toolkit that does not use
> > the OS Native UI widgets.
> 
> That's a shame. If you go native you'll have the "look and feel", but
> you'll have X times the work where X is the number of platforms
> supported. Also, each platform has its own bugs, so you'd have to
> write a lot of workaround code as well (e.g. wxWidgets is full of
> win32 workarounds).
> 
> Doing it non-native slows you down at first, but it gives you a lot
> more control on how you can render things. You can add a feature
> without having to worry on how to port the feature to other platforms.
> And finally, you can simulate the native windowing environment.
> 

While non-native does have certain potential benefits, it's ultimately
an inherently-flawed approach because the whole "simulate the native"
starts becoming under-valued.

This under-valuing is inevitable because not only is "simulate the
native" far harder to get right than it seems, but it turns
out not to even be realistically possible in many cases that aren't
immediately obvious, but are nonetheless important.

This inevitable "under-valuing" of "simulate the native" is
necessarily an erosion of respect for the user's property and
preferences. The convenience of the toolkit's developers, and app's
developers *becomes* the "center of the universe" so to speak.

But unfortunately, any time "the user" stops being the #1 priority, then
technology has already failed it's raison d'être. At that point,
nothing else matters and it's all becomes pointless waste of time.

tl;dr: Developing a non-native GUI is a cheap shortcut. The hidden cost
comes as severely diminished value for all software that uses it,
thus ultimately wasting everyone's time, including the toolkit's
original developers.

> Just to mention this, we already have native libraries (and written in
> D without wrapping C++ libs) such as DGUI, DFL, DWT. I hardly find
> them successful, they get the occasional pull request, but otherwise
> they seem to lack any sort of team effort or going-forward schedule.
> So I'd say going "native" has already been a failed experiment (take
> that with a huge grain of salt, it's just my personal viewpoint :) ).
> 

By the same token, we don't have any non-native GUIs in D that have
fared any better.

> 
> I have zero doubt that we have the know-how or hacking ability to
> actually work and solve GUI problems in D, but I have big doubts that
> we would ever have leadership that would make sure we have a proper
> schedule and todo list, proper discussions, the guts to say "no" to
> features, etc. It's just not going to work if people randomly create
> pull requests with some code they thought would be nice to include in
> a GUI library.
> 

I tend to feel the same way, to be honest.

Or rather, I suspect we may actually have the potential leadership, but
any such people are struggling to find the necessary time to
dedicate to it. Leadership is more than just the willingness and
ability to lead, but also about having the time (and any other
needed resources) with which to do it.