www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.dwt - Current state of DWT

reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
What's the current state of dwt and where can I find some 
toturials and/or example applications?

Thanks!
Jan 13 2021
parent reply Jacob Carlborg <doob me.com> writes:
On 2021-01-13 11:50, Imperatorn wrote:

 What's the current state of dwt and where can I find some toturials 
 and/or example applications?


The current state is that is in maintenance mode. I'm only make sure it 
works on the latest version of DMD. It does not receive any other form 
of updates.

When it comes to tutorials, you can use the same tutorials for SWT [1]. 
DWT is a port of SWT to D. There's also a bunch of snippets available 
here [2].

[1] https://www.eclipse.org/swt/
[2] 
https://github.com/d-widget-toolkit/dwt/tree/master/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets

-- 
/Jacob Carlborg
Jan 17 2021
next sibling parent reply mori <stigma disroot.org> writes:
On 18/1/21 5:59 am, Jacob Carlborg wrote:

 The current state is that is in maintenance mode. I'm only make sure it 
 works on the latest version of DMD. It does not receive any other form 
 of updates.


Given this, would it be correct to assume that you're not accepting pull 
requests that would update DWT?  Only asking because I'd be willing to 
help update the GNU/Linux side.
Jan 17 2021
parent reply Jacob Carlborg <doob me.com> writes:
On 2021-01-18 01:11, mori wrote:


 Given this, would it be correct to assume that you're not accepting pull 
 requests that would update DWT?  Only asking because I'd be willing to 
 help update the GNU/Linux side.


No, I will definitely accept pull requests. It's mostly that I don't 
have much time available and I think it's too tiresome to manually 
update. I've started a project to automatically translate Java code to D 
code [1] to be able to automatically update DWT. But again, due to time 
constraints I've not been able to work on that project for a while.

Although, I'm not sure how to best handle this if only Linux is going to 
be updated.

[1] https://github.com/d-widget-toolkit/jport

-- 
/Jacob Carlborg
Jan 18 2021
parent reply mori <stigma disroot.org> writes:
On 19/1/21 2:34 am, Jacob Carlborg wrote:

 On 2021-01-18 01:11, mori wrote:
 

 Given this, would it be correct to assume that you're not accepting 
 pull requests that would update DWT?  Only asking because I'd be 
 willing to help update the GNU/Linux side.


 
 No, I will definitely accept pull requests. It's mostly that I don't 
 have much time available and I think it's too tiresome to manually 
 update. I've started a project to automatically translate Java code to D 
 code [1] to be able to automatically update DWT. But again, due to time 
 constraints I've not been able to work on that project for a while.


Initially I'll try converting the manually so I can understand the 
internals a little (also don't know any Scala...).  The benefit of 
completing JPort is apparent though, so perhaps in the future.


 Although, I'm not sure how to best handle this if only Linux is going to 
 be updated.


Understandable.  However, this begs the question, is it worth it?

As mentioned, I'm happy to work on the Gtk side, but there isn't much 
merit in a "cross-platform" Toolkit which only supports one platform.

I do have an old Macbook Air (currently on 10.15 can be updated though), 
however, I'm a little uncertain on the current status of `extern 
(Objective-C)` (e.g. could a full binding for Cocoa be done?).  If it is 
possible, then I may be able to tinker away at that once the Gtk version 
is a bit more updated.

Anyway, I might still send some pull requests for Gtk, but what version 
of SWT should be aimed for?
Jan 18 2021
parent reply Jacob Carlborg <doob me.com> writes:
On 2021-01-19 05:51, mori wrote:

Sorry for the late reply. I keep forgetting to check this forum. There's 
usually not much activity here.


 Initially I'll try converting the manually so I can understand the 
 internals a little (also don't know any Scala...).


I didn't know any Scala before I started with JPort either. That didn't 
stop me. I picked Scala because JDT (Java the compiler library) I'm 
using is written in Java and I didn't want to write the tool in Java. In 
hindsight it might have been better to pick Java. Because, when the tool 
is ready you can automatically port SWT to D. But also, hopefully, port 
JDT and the tool itself to D :). Then we would both a have a tool that 
translates Java to D code and a Java compiler written in D. But now we 
would need to port the tool manually from Scala to D.


 The benefit of 
 completing JPort is apparent though, so perhaps in the future.


That would be nice. All contributions are welcome. IIRC correctly, 
translating of the syntax is done. Now it's the big part left, the 
semantic translations.


 Understandable.  However, this begs the question, is it worth it?


I don't know. It's up to you if you want to help. I'm just happy to get 
any help I can.


 As mentioned, I'm happy to work on the Gtk side, but there isn't much 
 merit in a "cross-platform" Toolkit which only supports one platform.


Hehe, yeah.


 I do have an old Macbook Air (currently on 10.15 can be updated though), 
 however, I'm a little uncertain on the current status of `extern 
 (Objective-C)` (e.g. could a full binding for Cocoa be done?).  If it is 
 possible, then I may be able to tinker away at that once the Gtk version 
 is a bit more updated.


Yeah, that's the embarrassing thing. macOS is my main platform, I've 
implemented the support for `extern (Objective-C)` and native TLS on 
macOS, but there's no macOS port of DWT. I've started on a port many 
years ago [1]. It's still written in D1. The plan was to complete the 
port in D1 before translating it to D2 (there's some info in the 
readme). This is way before the support for `extern (Objective-C)`, 
which is only in D2.

When it comes to the status of the Objective-C integration. The last 
release of DMD (2.095.0) added support for interfacing with Objective-C 
protocols. This is, more or less, the final piece to be able to properly 
use the Objective-C APIs. There are a few problems though, which there 
are some workarounds for:

* There's a bug in the code that DMD geberates, where compiled 
executable code segfaults for any method that returns a struct that is 
too large to fit in registers. On x86-64, this is 16 bytes, IIRC. This 
is the most severe problem.

* LDC has not kept up to date with the Objective-C integration, it only 
supports the first iteration that DMD implemented. That is, support for 
instance methods. Of course, LDC doesn't have the above bug :)

* There's no language support for blocks. I'm not sure if SWT uses any 
APIs which require blocks. It's possible to implement block support in 
library code [2]

* In Objective-C there's both a class and a protocol (interface) which 
is named NSObject. This is not possible in D. We need language support 
to change the name which is output in the binary (something like 
`pragma(mangle)`. A workaround is to add the methods which are declared 
in the protocol to the class instead. Or/and any protocols that inherits 
form the NSObject protocol and not include the NSObject protocol at all.


 Anyway, I might still send some pull requests for Gtk, but what version 
 of SWT should be aimed for?


That's a good question. It's probably easier to do incremental updates, 
i.e. pick some old version which is newer then DWT.

[1] https://github.com/d-widget-toolkit/dwt-mac
[2] 
https://github.com/dlang/druntime/pull/1582/files#diff-0b75a0e079a2a997c1c32e5da529db020232a8d4e7686591d0c710085c4e26d3

-- 
/Jacob Carlborg
Jan 23 2021
parent reply mori <stigma disroot.org> writes:
On 23/1/21 6:39 pm, Jacob Carlborg wrote:

 Sorry for the late reply.


All good.


 [...] 
 In hindsight it might have been better to pick Java. Because, when the tool 
 is ready you can automatically port SWT to D. But also, hopefully, port 
 JDT and the tool itself to D :). Then we would both a have a tool that 
 translates Java to D code and a Java compiler written in D. But now we 
 would need to port the tool manually from Scala to D


It would be nice to have everything written in D eventually.


 Understandable.  However, this begs the question, is it worth it?


 
 I don't know. It's up to you if you want to help. I'm just happy to get 
 any help I can.


I feel as if I came across rather... pessimistic.  I do want to help.

 I do have an old Macbook Air (currently on 10.15 can be updated 
 though), however, I'm a little uncertain on the current status of 
 `extern (Objective-C)` (e.g. could a full binding for Cocoa be 
 done?).  If it is possible, then I may be able to tinker away at that 
 once the Gtk version is a bit more updated.


 
 Yeah, that's the embarrassing thing. macOS is my main platform, I've 
 implemented the support for `extern (Objective-C)` and native TLS on 
 macOS, but there's no macOS port of DWT.


Yesterday I spent some time trying to port the (cocoa) Program class to 
D using `extern (Objective-C)`.  What I've got works, but the main 
difference (as you'd probably know) is that Java the Objective-C lib 
itself (i.e. <objc/*.h>) which allows them to create instances with 
`new`.  This (seemingly) isn't possible with `extern (Objective-C)` classes.


 I've started on a port many years ago [1]. It's still written in D1.
 The plan was to complete the port in D1 before translating it to D2
 (there's some info in the readme). This is way before the support for
`extern (Objective-C)`, which is only in D2.


I'll use that code as a base, but did you want to stick to using the 
`objc_msgSend` style code or `extern (Objective-C)`?

Also (this applies to Gtk as well), did you want me to send pull 
requests against the main DWT repository, or the individual repositories?


 When it comes to the status of the Objective-C integration. The last 
 release of DMD (2.095.0) added support for interfacing with Objective-C 
 protocols. This is, more or less, the final piece to be able to properly 
 use the Objective-C APIs.


That's good news!


 There are a few problems though, which there are some workarounds for:
 
 * There's a bug in the code that DMD geberates, where compiled 
 executable code segfaults for any method that returns a struct that is 
 too large to fit in registers. On x86-64, this is 16 bytes, IIRC. This 
 is the most severe problem.


Haven't run into this issue myself yet, but will keep it mind.


 * There's no language support for blocks. I'm not sure if SWT uses any 
 APIs which require blocks. It's possible to implement block support in 
 library code [2]


A quick search of the SWT repository shows that they have something in 
place[3], so it's likely.

[3]: 
https://github.com/eclipse/eclipse.platform.swt/blob/R4_7_3/bundles/org.eclipse.swt/Eclipse%20SWT%20PI/cocoa/library/os_custom.c#L248


 Anyway, I might still send some pull requests for Gtk, but what 
 version of SWT should be aimed for?


 
 That's a good question. It's probably easier to do incremental updates, 
 i.e. pick some old version which is newer then DWT.


I mentioned why I chose 4.7.3 in the pull request, but there is also the 
benefit that doesn't depend on `gnomeui` and `gnomevfs` which aren't 
available in some package repositories now. (Mainly Debian based it seems.)

I don't imagine there are any broken APIs in the win32 version 
(Microsoft is good with backwards compatibility after all), just not 
sure on the Cocoa side.


 [1] https://github.com/d-widget-toolkit/dwt-mac
 [2] 
 https://github.com/dlang/druntime/pull/1582/files#diff-0b75a0e079a2a997c1c32e5da529db020232a8d4e768
591d0c710085c4e26d3
Jan 23 2021
parent Jacob Carlborg <doob me.com> writes:
On 2021-01-24 04:50, mori wrote:


 I feel as if I came across rather... pessimistic.  I do want to help.


Awesome :)


 Yesterday I spent some time trying to port the (cocoa) Program class to 
 D using `extern (Objective-C)`.  What I've got works, but the main 
 difference (as you'd probably know) is that Java the Objective-C lib 
 itself (i.e. <objc/*.h>) which allows them to create instances with 
 `new`.  This (seemingly) isn't possible with `extern (Objective-C)` 
 classes.


Yes, that's correct. The way Eclipse has created the Objective-C 
bindings is to wrap all Objective-C classes in Java classes. That means 
that for each Objective-C object there will also be a Java object. This 
is to create friendlier API. But in D, since there's direct language 
support for using Objective-C classes, that's not necessary. There will 
only be an Objective-C object.

Instead of Java code looking like this:

NSAlert alert = (NSAlert) new NSAlert().alloc().init();

The D code will look just like this:

NSAlert alert = NSAlert.alloc().init();


 I'll use that code as a base, but did you want to stick to using the 
 `objc_msgSend` style code or `extern (Objective-C)`?


It's better to use the `extern (Objective-C)` style. This will result in 
the code looking slightly less like the Java code, but it will be more 
correct.


 Also (this applies to Gtk as well), did you want me to send pull 
 requests against the main DWT repository, or the individual repositories?


I guess you have already figured this out, but the 
org.eclipse.swt.win32.win32.x86, org.eclipse.swt.snippets and 
org.eclipse.swt.gtk.linux.x86 repositories have been merged into the dwt 
repository.

As for the Cocoa port. It depends on what approach you want to take. 
Finish the existing port in D1 or start fresh and incrementally porting 
4.7.3. For the one doing the code reviews, it's much easier if the diffs 
are smaller.


 Haven't run into this issue myself yet, but will keep it mind.


As soon as some methods return NSRect you'll run into this. A workaround 
is to manually call the Objective-C runtime function `objc_msgSend_stret`.

Also, keep in mind that `float` and `double` are initialized to 0.0 by 
default in Java, while in D they're initialized to NaN.


 I mentioned why I chose 4.7.3 in the pull request, but there is also the 
 benefit that doesn't depend on `gnomeui` and `gnomevfs` which aren't 
 available in some package repositories now. (Mainly Debian based it seems.)


Since you're the one doing the work and if 4.7.3 is fine with you, then 
that's great.


 I don't imagine there are any broken APIs in the win32 version 
 (Microsoft is good with backwards compatibility after all), just not 
 sure on the Cocoa side.


Apple has a tendency to, not necessarily break APIs but change things 
that might cause problems. Especially if applications are not 
implemented the way that Apple thinks they should be implemented. Like 
dark mode. They do deprecate APIs as well.

-- 
/Jacob Carlborg
Jan 24 2021
prev sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 17 January 2021 at 19:59:38 UTC, Jacob Carlborg wrote:

 On 2021-01-13 11:50, Imperatorn wrote:

 What's the current state of dwt and where can I find some 
 toturials and/or example applications?


 The current state is that is in maintenance mode. I'm only make 
 sure it works on the latest version of DMD. It does not receive 
 any other form of updates.

 When it comes to tutorials, you can use the same tutorials for 
 SWT [1]. DWT is a port of SWT to D. There's also a bunch of 
 snippets available here [2].

 [1] https://www.eclipse.org/swt/
 [2] 
 https://github.com/d-widget-toolkit/dwt/tree/master/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets


Ok, thanks for your efforts. I'm just wondering what the 
"official" ui framework is considered to be, looking around 👍
Jan 17 2021
parent Jacob Carlborg <doob me.com> writes:
On 2021-01-18 07:22, Imperatorn wrote:


 Ok, thanks for your efforts. I'm just wondering what the "official" ui 
 framework is considered to be, looking around 👍


At one point DWT was named to be the official GUI framework for D :). Of 
course, that didn't mean anything. No additonal contributors, fundings 
or similar.

-- 
/Jacob Carlborg
Jan 18 2021