Thread overview
DWT Support Docs for Windows
Feb 07
JamesD
Feb 10
JamesD
Feb 20
JamesD
February 07
I'm a programming hobbyist and I'm new to the D language.  I've recently struggled to get a GUI working on Windows. I finally made some progress, and have created a few docs that I hope will help others.  Constructive feedback is welcome.

The following are on https://github.com/jasc2v8/dwt-support under \doc:

1. Why use the DWT GUI for the D Language
2. Config DWT GUI for Eclipse DDT on Windows
3. Build DWT 64 bit on Windows
February 08
On 2017-02-07 22:48, JamesD wrote:
> I'm a programming hobbyist and I'm new to the D language.  I've recently
> struggled to get a GUI working on Windows. I finally made some progress,
> and have created a few docs that I hope will help others.  Constructive
> feedback is welcome.
>
> The following are on https://github.com/jasc2v8/dwt-support under \doc:
>
> 1. Why use the DWT GUI for the D Language
> 2. Config DWT GUI for Eclipse DDT on Windows
> 3. Build DWT 64 bit on Windows

That's great. A few comments:

* Since DMD 2.073.0 (I believe) Dub is included

* I don't know how the dub.json file that DDT creates looks like. But usually with Dub you build a release build with the following command: "dub build -b release". See "dub build -h" for more information, there are some other build types available as well

* About the disadvantages, in my opinion, native widgets is an advantage. I guess there are two kinds of people, those that like native widgets and those who don't

-- 
/Jacob Carlborg
February 10
On Wednesday, 8 February 2017 at 14:45:44 UTC, Jacob Carlborg wrote:
> On 2017-02-07 22:48, JamesD wrote:
>> I'm a programming hobbyist and I'm new to the D language.  I've recently
>> struggled to get a GUI working on Windows. I finally made some progress,
>> and have created a few docs that I hope will help others.  Constructive
>> feedback is welcome.
>>
>> The following are on https://github.com/jasc2v8/dwt-support under \doc:
>>
>> 1. Why use the DWT GUI for the D Language
>> 2. Config DWT GUI for Eclipse DDT on Windows
>> 3. Build DWT 64 bit on Windows
>
> That's great. A few comments:
>
> * Since DMD 2.073.0 (I believe) Dub is included
>
> * I don't know how the dub.json file that DDT creates looks like. But usually with Dub you build a release build with the following command: "dub build -b release". See "dub build -h" for more information, there are some other build types available as well
>
> * About the disadvantages, in my opinion, native widgets is an advantage. I guess there are two kinds of people, those that like native widgets and those who don't

Thank you for your constructive feedback - very much appreciated!

You are correct, the DMD download includes DUB, I updated the doc.
(I noticed that DMD also prompts to download VS if you require 64bit support)

The Eclipse DDT plugin creates a shell dub.json.  My doc "Config DWT GUI for Eclipse DDT on Windows" shows how to edit this dub.json to reference the DWT imports and libraries.

The Eclipse DDT plugin basically executes the "dub build -b" command.  By default, it is the debug version.  Also by default, dub reads the dub.json file so the app.d can link to the DWT libraries.

The user can certainly execute the commands manually or in a windows batch file - I'm working on another doc for that process as well.

I agree with you about the native widgets, so I updated my other doc as well.

February 10
On 2017-02-10 03:11, JamesD wrote:

> The Eclipse DDT plugin creates a shell dub.json.  My doc "Config DWT GUI
> for Eclipse DDT on Windows" shows how to edit this dub.json to reference
> the DWT imports and libraries.
>
> The Eclipse DDT plugin basically executes the "dub build -b" command.
> By default, it is the debug version.  Also by default, dub reads the
> dub.json file so the app.d can link to the DWT libraries.
>
> The user can certainly execute the commands manually or in a windows
> batch file - I'm working on another doc for that process as well.

Claiming that there are only two build targets, default and unittest, is not correct. Perhaps it's only possible to build these two targets from DDT.

I don't think it's the right approach to hijack the "unittest" target to build a release build. If the issue is that DDT can only build two targets than that should: A. be fixed, B. be properly explained in your docs and that it's possible to build the release target from the command line.

Since DDT, I assume, is leveraging Dub to do all the dependency tracking, configuration and building it's very simple to build in the same way as DDT does on the command line.

-- 
/Jacob Carlborg
February 20
On Friday, 10 February 2017 at 07:44:15 UTC, Jacob Carlborg wrote:
> On 2017-02-10 03:11, JamesD wrote:
>
>> The Eclipse DDT plugin creates a shell dub.json.  My doc "Config DWT GUI
>> for Eclipse DDT on Windows" shows how to edit this dub.json to reference
>> the DWT imports and libraries.
>>
>> The Eclipse DDT plugin basically executes the "dub build -b" command.
>> By default, it is the debug version.  Also by default, dub reads the
>> dub.json file so the app.d can link to the DWT libraries.
>>
>> The user can certainly execute the commands manually or in a windows
>> batch file - I'm working on another doc for that process as well.
>
> Claiming that there are only two build targets, default and unittest, is not correct. Perhaps it's only possible to build these two targets from DDT.
>
> I don't think it's the right approach to hijack the "unittest" target to build a release build. If the issue is that DDT can only build two targets than that should: A. be fixed, B. be properly explained in your docs and that it's possible to build the release target from the command line.
>
> Since DDT, I assume, is leveraging Dub to do all the dependency tracking, configuration and building it's very simple to build in the same way as DDT does on the command line.

Thank you for your constructive feedback!

Correct, only 2 build targets in DDT at this time;
    (default)
    (default):unittest

I agree that hijacking unittest is not the best approach.  What I am doing now is to edit the (default) build target as follows.

    Original: ${DUB_TOOL_PATH} build
    Modified: ${DUB_TOOL_PATH} build -b=release

I leave the (default):unittest unmodified as follows.

    Original: ${DUB_TOOL_PATH} build -b unittest

Thanks for your suggestions about updating my docs. I plan to as I learn and time permitting.

Yes, DDT is indeed leveraging DUB to do the builds.  Obviously, DDT will allow me to crate a batch file or whatever for other build methods, but DUB is convenient for linking with the DWT library.





February 22
On 2017-02-20 05:25, JamesD wrote:

> Thank you for your constructive feedback!
>
> Correct, only 2 build targets in DDT at this time;
>     (default)
>     (default):unittest
>
> I agree that hijacking unittest is not the best approach.  What I am
> doing now is to edit the (default) build target as follows.
>
>     Original: ${DUB_TOOL_PATH} build
>     Modified: ${DUB_TOOL_PATH} build -b=release
>
> I leave the (default):unittest unmodified as follows.
>
>     Original: ${DUB_TOOL_PATH} build -b unittest

Sounds reasonable. Can you add additional build targets, one for the release?

> Thanks for your suggestions about updating my docs. I plan to as I learn
> and time permitting.
>
> Yes, DDT is indeed leveraging DUB to do the builds.  Obviously, DDT will
> allow me to crate a batch file or whatever for other build methods, but
> DUB is convenient for linking with the DWT library.

I'm not saying that you would not use Dub to do the build, just invoke it differently, as you done above.

-- 
/Jacob Carlborg