On Wednesday, 31 July 2013 at 21:30:43 UTC, Jeremy DeHaan wrote:
> On Monday, 29 July 2013 at 09:47:09 UTC, Trvhgoy wrote:
>> Hello,
>> is there somebody who works on an open source integrated
>> developement environment written in D?
>> I have heared of Poseiden, but nobody works actively on it, right?
>>
>> Regards Trvhgoy
>
> I was actually going to start work on a D IDE pretty soon. I just needed to wrap up some other projects first. I was going to use gtkD as the GUI system for it though. Creating a new UI for D would be a pretty huge undertaking!

In the current state I would design the architecture of an IDE so that you can easily (more or less) change the used GUI system.
Just a first idea: maybe some kind of the abstract factory pattern.

On Monday, 29 July 2013 at 16:34:27 UTC, Trvhgoy wrote:

> Is it right, that DWT is not further developed?

DWT is still being maintained. Basically just so it will compile with the latest compiler. I'm currently focusing on (slowly) finish the Mac OS X port. Any help is welcome.

--
/Jacob Carlborg

On Monday, 5 August 2013 at 14:50:59 UTC, Jacob Carlborg wrote:
> On Monday, 29 July 2013 at 16:34:27 UTC, Trvhgoy wrote:
>
>> Is it right, that DWT is not further developed?
>
> DWT is still being maintained. Basically just so it will compile with the latest compiler. I'm currently focusing on (slowly) finish the Mac OS X port. Any help is welcome.
>
> --
> /Jacob Carlborg

Oh that's good news. :)
DWT is more what I'm looking for (not just a wrapper like GtkD).
I will have a further look on it and maybe build some something
with DWT.
Thanks for the information and for working on DWT.

On Tuesday, 6 August 2013 at 06:43:54 UTC, Trvhgoy wrote:
> On Monday, 5 August 2013 at 14:50:59 UTC, Jacob Carlborg wrote:
>> On Monday, 29 July 2013 at 16:34:27 UTC, Trvhgoy wrote:
> Oh that's good news. :)
> DWT is more what I'm looking for (not just a wrapper like GtkD).

I have a question about DWT: the fact that is (largely) a wrapper for native widgets, that is widgets provided by the operating system... won't make this kind of toolkit inappropriate for... writing user interfaces of operating systems?

Imagine that one day you are writing the next version of Windows, from scratch, in D. What you will wrap in order to provide the widgets?

From this point of view, I tend to think that a Swing/AWT-like approach is the better choice. This is also why I pushed a bit for FOX Toolkit.

On 2013-08-06 09:09, eles wrote:

> I have a question about DWT: the fact that is (largely) a wrapper for
> native widgets, that is widgets provided by the operating system...
> won't make this kind of toolkit inappropriate for... writing user
> interfaces of operating systems?
>
> Imagine that one day you are writing the next version of Windows, from
> scratch, in D. What you will wrap in order to provide the widgets?

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. You could theoretically decided that the Windows GUI API would be the same as DWT and then you could use it directly. Or, the DWT implementation for this Windows version would be very small and light.

Note that DWT contains quite a lot of code making the widgets behave somewhat similar on all platforms.

>  From this point of view, I tend to think that a Swing/AWT-like approach
> is the better choice. This is also why I pushed a bit for FOX Toolkit.

AWT uses native widgets as well.

-- 
/Jacob Carlborg

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.

On Tuesday, 6 August 2013 at 12:23:41 UTC, eles wrote:
>
> 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.

what? O_o
we are not talking about "native" GUI, original question is about how much do we need an IDE(preferably written in D), i just point that not IDE should be done first, but GUI(which provides much more opportunities than IDE). because in my opinion(no, i'm not UI/UX expert) we have GUI toolkit crisis, there are almost no declarative crossplatform(i mean major OS) toolkit for writing simple yet highly customizable UI's, with HTML markup-like, customizable UI's without messing with imperative(C/C++/D/whatever) code. that's how i see a "must have" GUI lib, not all that gtk/qt/swing crap, we should program algorithms, not ui widgets!
(i repeat, i'm not UI/UX expert, but have some little sad experience with existing libs(except WPF))

On 2013-08-06 14:23, eles wrote:

> 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.

If a widget isn't available on a given platform one would have to implement that using the graphics primitives, that's also what DWT does.

> 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.

You would still need to some graphics primitives. Do you want to implement them yourself as well? I mean, you have to draw the line somewhere. There's always a layer beneath you that you rely on, if you're not doing embedded or similar.

> 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*)

You will always have to rely on something else, see above.

> I think that providing only a wrapper of native widgets will make
> writing native widgets in D less appealing.

So you want a non-native toolkit.

-- 
/Jacob Carlborg

On Wednesday, 7 August 2013 at 09:58:15 UTC, Jacob Carlborg wrote:
> On 2013-08-06 14:23, eles wrote:
> If a widget isn't available on a given platform one would have to implement that using the graphics primitives, that's also what DWT does.

It does, but only for those platforms where those widgets are not available. For many widgets on Windows, it does not. How would you write those widgets for the next version of Windows?

> You would still need to some graphics primitives. Do you want to implement them yourself as well? I mean, you have to draw the line somewhere. There's always a layer beneath you that you rely on, if you're not doing embedded or similar.

[First: this is a doubt that I have, is not a war]

Yes. But, for systems languages, I have the feeling that the line should be lower. You could not very much rely on a system to write a system (especially when the two systems are... the same). I was pointing to drivers as the lower bound in my original post. The rest should be drawn...

> So you want a non-native toolkit.

I think so.

On 2013-08-07 16:20, eles wrote:

> It does, but only for those platforms where those widgets are not
> available. For many widgets on Windows, it does not. How would you write
> those widgets for the next version of Windows?

As I said, use some form of graphics primitives. These would be implemented on top of OpenGL or DirectX. OpenGL is implemented in the graphics drivers, don't know how it works with DirectX.

-- 
/Jacob Carlborg