Current state of DWT

[Jacob Carlborg]

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