Ideal D GUI Toolkit

[Kiith-Sa]

On Tuesday, 21 May 2013 at 11:06:44 UTC, Andrej Mitrovic wrote:
> On 5/21/13, Adam Wilson <flyboynw at gmail.com> wrote:
>> Well, it comes down to how you want to render. My preferred 
>> solution
>> woulbd be a rendering thread running all the time doing 
>> nothing but the
>> GPU leg-work
>
> Why a GPU? Aren't most GUIs static? And aren't there issues 
> with GPUs
> where feature X isn't supported on all GPUs or is buggy on a
> particular one (e.g. driver issues)? Or maybe that was true in 
> the
> past, I was out of the loop for a while. :)

If you only use basic features (everything you need for GUI), 
you're not going to have issues. In any case if you go the GPU 
route it's best to isolate the GPU code behind an interface so 
you can add a software implementation later if absolutely 
necessary.

I think the best idea is to stop arguing and just do something. I 
recommend trying a minimalist project (at most Clutter sized) 
instead of something massive like Qt that's likely never going to 
see the light of day. Implement the basics, create a few example 
apps, and _then_ start a discussion. You might not get a perfect 
library/framework, but at least you'll get something that exists 
instead of an infinite flame war getting nowhere as is the 
tradition in the D world. Getting more than one contributor _and_ 
not stopping work on it is going to be the main issue, there've 
been a few D GUI attempts and they're mostly dead due to lost 
interest.

My (subjective) preferences:

* Human-readable markup, not just through a tool (a tool can be 
built later). YAML and JSON work well here.

* Look at Hybrid API. Clutter and Qt also have nice APIs, but D 
allows some things not possible there.

* Library instead of a framework - one of things I like about the 
Hybrid design