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