Ideal D GUI Toolkit

[Andrej Mitrovic]

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.

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

> * Nobody believes that we can do it, you'll hear a lot of moaning about
> how much work it is. My reply to that is: And Linux is such a piece of
> cake right? It's only the most widely used kernel on the planet.

I think the lesson with Linux is that one person initially did a lot
of heavy lifting, and then others joined in. I doubt it would work as
it did if instead Linus opened a thread asking for a team of
developers to create a new OS from scratch.

Anyway, there's no doubt a D GUI would be a huge undertaking. There
would almost certainly be a lot of rewriting involved. It's very easy
to make mistakes early on and hardcode something, only later to
realize it's way too brittle so it requires a rewrite. If the system
is modular enough then the rewrites become less painful. And if the
system is properly unit tested then regressions become less likely,
and this is important.

>From what I've seen when a codebase becomes large enough, what
inevitably happens is people stop hacking on the codebase almost
entirely. It's usually because the codebase is huge and not modular,
or undocumented, or not tested, or doesn't have any sort of schedule
on the work that needs to be done.

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.

So to actually do it, I think we need:

1) A "core" for a GUI library written in D that people can start
hacking on (meaning you can create windows, and draw in a pixel
buffer, capture device input, all platform-independent), and

2) Solid leadership.

I'd say #2 is more important than #1, because #1 is something many
people can do, and #2 is the really hard bit.