Current state of DWT
mori
stigma at disroot.org
Sun Jan 24 03:50:53 UTC 2021
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
More information about the Digitalmars-d-dwt
mailing list