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
