Ideal D GUI Toolkit

Adam Wilson flyboynw at gmail.com
Mon May 20 14:01:38 PDT 2013


On Mon, 20 May 2013 13:58:04 -0700, Timothee Cour  
<thelastmammoth at gmail.com> wrote:

>>
>> The following will take much less time and can achieve good, native
>> results quickly:
>>
>> Design a user-code facing clean api using idiomatic D (front end code):
>> windows, widgets, callbacks via delegates, etc.
>> Design a glue layer to talk to different backends: gtkd, wxd, qtd, fltk
>> etc.
>>
>> This is what python does with matplotlib:
>> http://matplotlib.org/faq/usage_faq.html : they support pygtk, wxpython,
>> tkinter, qt, macosx, or fltk, and also non interactive backends)
>> The user code stays clean, the results are native (depending on  
>> backend),
>> and the wheel is not reimplemented.
>>
>>
> The other advantage of this is we can have results early on (leveraging
> existing backends), but nothing prevents us to work in parallel on a
> backend that's purely written in D (written on top of opengl for example)
> if need be.

Every design I've discussed with various people in the community relies on  
have a pluggable rendering backend. It's the only sensible way really, the  
best way to custom draw stuff on Windows is DirectX, whereas its OGL on  
Linux/Mac, or OpenGL ES on Android and iOS.

And by going straight for the lowest level of GPU interaction for each  
platform we avoid an extra layer of abstraction in the rendering pipeline,  
which is very performance sensitive.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/


More information about the Digitalmars-d mailing list