Current state of DWT

[mori]

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-0b75a0e079a2a997c1c32e5da529db020232a8d4e7686591d0c710085c4e26d3