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