Ideal D GUI Toolkit

[Tyler Jameson Little]

On Tuesday, 21 May 2013 at 11:33:19 UTC, Kiith-Sa wrote:
> 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