IDE written in D
eles
eles at eles.com
Tue Aug 6 05:23:39 PDT 2013
On Tuesday, 6 August 2013 at 11:42:33 UTC, Jacob Carlborg wrote:
> On 2013-08-06 09:09, eles wrote:
>
> I'm not sure I understand the question. You would create the
> GUI in D just as it's now in C or C++. Then you would wrap the
> widgets, just as know, in the DWT interface.
Yes, but in order to create the GUI (remember, you have no
widgets to wrap), I tend to think it would be better to have the
toolkit designing its own widgets (you will still need some
graphic primitives, but that is basically drivers).
For example, how you wold solve this problem with DWT or any
other wrapper toolkit:
"implement a calendar-like widget for an operating system"
You cannot rely on wrapping a "calendar" widget of the OS' GUI,
simply because you are writing the GUI.
OTOH, if the toolkit designs its own widgets (in terms of "draw
pixel; draw line" etc.), you could build up the GUI of the OS
itself.
In my view, a systems programming language should not rely on the
fact that widgets already exist and only needs to wrap those.
Yes, C++ GUI libraries, many of them, rely on that assumption;
however, none of them is standard.
Imagine the guys at Microsoft writing the basic DLLs that provide
the user the pushbutton, the radiobutton etc. They have no
previously existing widgets to wrap. They are creating the
widgets that others will wrap.
So, what a systems language should provide in its *standard*
toolkit? Something that could be run on the bare metal and allow
building on top of it, or something that rely on already having
those things written by somebody else? Who will write this "else"
and in what language, and with what library? (it still could be
in D, but *without the support of the standard toolkit*)
I think that providing only a wrapper of native widgets will make
writing native widgets in D less appealing.
More information about the Digitalmars-d-ide
mailing list