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
