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.

On Mon, May 20, 2013 at 1:20 PM, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:
On Mon, 20 May 2013 12:41:08 -0700
"Adam Wilson" <flyboynw@gmail.com> wrote:

> On Mon, 20 May 2013 12:28:16 -0700, Dmitry Olshansky
> <dmitry.olsh@gmail.com> wrote:
> >
> > Markup for GUI layout seems like a decent idea.
> >
>
> HTML is markup. XAML is markup. QML is markup. XUL is markup. iOS is
> markup. Android is markup. Realistically, the age of OS native
> toolkits has passed, markup is the future. *shrug* For me it's a
> practical thing,

And what takes that markup and actually executes it? Magical GUI
fairies? ;)

Markup is, by necessity, nothing more than a front-end for a
code-based GUI engine/toolkit/whatever-we-want-to-call-it. The GUI
toolkits will always be there whether it's the UI designers that use it
directly or the markup developers that use it directly.

>markup is extensible, OS widgets are not.
>

I don't know where you got that idea.