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