Re: Current state of DWT
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. ) 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
Re: Current state of DWT
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
Re: Current state of DWT
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
Re: Current state of DWT
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
Re: Current state of DWT
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
Re: DWT doesn't compile with dmd 2.87.0
On 2019-07-14 19:00, Patrick Schluter wrote: DWT doesn't build anymore with the new compiler. Wasn't DWT supposed to be part of the build job of compiler so that regressions are caught in time? dwt 1.0.1+swt-3.4.1: building configuration "windows-win32"... C:\Users\Patri\AppData\Local\dub\packages\dwt-1.0.1_swt-3.4.1\dwt\org.eclipse.swt.win32.win32.x86\src\org\eclipse\swt\internal\gdip\Gdip.d(478,9): Deprecation: The delete keyword has been deprecated. Use object.destroy() (and core.memory.GC.free() if applicable) instead. C:\Users\Patri\AppData\Local\dub\packages\dwt-1.0.1_swt-3.4.1\dwt\org.eclipse.swt.win32.win32.x86\src\org\eclipse\swt\ole\win32\OleControlSite.d(886,43): Error: class `org.eclipse.swt.ole.win32.OleControlSite.OleControlSite` member AddRef is not accessible C:\Users\Patri\AppData\Local\dub\packages\dwt-1.0.1_swt-3.4.1\dwt\org.eclipse.swt.win32.win32.x86\src\org\eclipse\swt\ole\win32\OleControlSite.d(906,43): Error: class `org.eclipse.swt.ole.win32.OleControlSite.OleControlSite` member AddRef is not accessible C:\Users\Patri\AppData\Local\dub\packages\dwt-1.0.1_swt-3.4.1\dwt\org.eclipse.swt.win32.win32.x86\src\org\eclipse\swt\widgets\IME.d(506,29): Deprecation: The delete keyword has been deprecated. Use object.destroy() (and core.memory.GC.free() if applicable) instead. C:\D\dmd2\windows\bin\dmd.exe failed with exit code 1. A new release has been made available: https://github.com/d-widget-toolkit/dwt/releases/tag/v1.0.2%2Bswt-3.4.1 In the future, please report an issue here: https://github.com/d-widget-toolkit/dwt/issues -- /Jacob Carlborg
Re: DWT doesn't compile with dmd 2.87.0
On 2019-07-14 19:00, Patrick Schluter wrote: DWT doesn't build anymore with the new compiler. Wasn't DWT supposed to be part of the build job of compiler so that regressions are caught in time? dwt 1.0.1+swt-3.4.1: building configuration "windows-win32"... C:\Users\Patri\AppData\Local\dub\packages\dwt-1.0.1_swt-3.4.1\dwt\org.eclipse.swt.win32.win32.x86\src\org\eclipse\swt\internal\gdip\Gdip.d(478,9): Deprecation: The delete keyword has been deprecated. Use object.destroy() (and core.memory.GC.free() if applicable) instead. C:\Users\Patri\AppData\Local\dub\packages\dwt-1.0.1_swt-3.4.1\dwt\org.eclipse.swt.win32.win32.x86\src\org\eclipse\swt\ole\win32\OleControlSite.d(886,43): Error: class `org.eclipse.swt.ole.win32.OleControlSite.OleControlSite` member AddRef is not accessible C:\Users\Patri\AppData\Local\dub\packages\dwt-1.0.1_swt-3.4.1\dwt\org.eclipse.swt.win32.win32.x86\src\org\eclipse\swt\ole\win32\OleControlSite.d(906,43): Error: class `org.eclipse.swt.ole.win32.OleControlSite.OleControlSite` member AddRef is not accessible C:\Users\Patri\AppData\Local\dub\packages\dwt-1.0.1_swt-3.4.1\dwt\org.eclipse.swt.win32.win32.x86\src\org\eclipse\swt\widgets\IME.d(506,29): Deprecation: The delete keyword has been deprecated. Use object.destroy() (and core.memory.GC.free() if applicable) instead. C:\D\dmd2\windows\bin\dmd.exe failed with exit code 1. As a workaround you can disable deprecation messages by adding "silenceDeprecations" to the "buildRequirements" setting in your Dub file. -- /Jacob Carlborg
Re: DWT doesn't compile with dmd 2.87.0
On 2019-07-16 15:27, knt.roh wrote: https://github.com/d-widget-toolkit/dwt/pull/47 I have sent this pull request. If this PR is merged and the dub package is updated, then this problem is probably fixed. Seems he has a different issue. Your PR fixes an error. He's getting deprecation messages. -- /Jacob Carlborg
Re: DWT doesn't compile with dmd 2.87.0
On 2019-07-14 19:00, Patrick Schluter wrote: Wasn't DWT supposed to be part of the build job of compiler so that regressions are caught in time? Yes, but that's only for Linux. -- /Jacob Carlborg
Re: Is DWT usable?
On 2018-04-23 08:09, dangbinghoo wrote: No, I'm just running in XFCE, and I think dwt also need to running with KDE. Yes, I'm just trying to rule out as much as possible to be able to fix this issue. -- /Jacob Carlborg
Re: Is DWT usable?
On 2018-04-17 11:42, dangbinghoo wrote: both archlinux (updated) and deepin linux 15(same core as debain 8). Are those platforms using KDE? Might be the same as this issue [1]. [1] https://github.com/d-widget-toolkit/dwt/issues/34 -- /Jacob Carlborg
Re: Is DWT usable?
On 2018-04-16 06:24, dangbinghoo wrote: I have noticed DWT moved to as a dub package. And said it easy to startup. So, I just cloned the DWT git repo. And did the same thing as README. But I got the following : ``` dub --single main.d Performing "debug" build using /usr/bin/dmd for x86_64. dwt:base 1.0.1+swt-3.4.1.commit.2.gd729d7d: target for configuration "library" is up to date. dwt 1.0.1+swt-3.4.1.commit.2.gd729d7d: target for configuration "linux-gtk" is up to date. main ~master: building configuration "application"... Linking... To force a rebuild of up-to-date targets, run again with --force. Running ./main Program exited with code -11 ``` the same result as I tried half year ago. Which platform are you using? -- /Jacob Carlborg
Re: GtkD global font size
On 2018-01-15 00:55, Sai wrote: I am writing a small GUI application using GtkD3 Builder and Glade. On a HD monitor the default font size is too small. The adwaita theme is not great but I can live with it. Is there any way to globally increase the font size in the GtkD? I tried the settings.ini file, but that did not help with my GtkD3 app. On the other hand, it did increase the global font size of the Glade tool, just not my application. Is some how GtkD different from pure Gtk application? This is the forum for the DWT library. I suggest you try the "learn" forum instead. -- /Jacob Carlborg
Re: Problem building SWTSnippets with D 2.074.x
On 2017-06-02 16:01, Jacob Carlborg wrote: This is due to a regression in the compiler [1]. Please use 2.073.x until this has been fixed. [1] https://issues.dlang.org/show_bug.cgi?id=17371 The issue has now been fixed. We'll see in which release of the compiler it will show up. -- /Jacob Carlborg
Re: DWT is official ?
On 2017-07-13 21:45, Jacob Carlborg wrote: Not sure what you mean with "official". The forum or the library? The forum is the official DWT forum. At one point it was announced that DWT would be the official GUI library for D. In practice nothing change. It's not considered the official GUI library anymore. -- /Jacob Carlborg
Re: DWT is official ?
On 2017-07-12 14:36, Flaze07 wrote: I see... so...is it official ?? Not sure what you mean with "official". The forum or the library? -- /Jacob Carlborg
Re: DWT is official ?
On 2017-07-12 12:10, Flaze07 wrote: hi...so is this group forum about the SWT D bindings ? (I am just surprised that it is...in the ecosystem if it is what I think it is) Technically DWT [1] is a port of SWT to D, not bindings. No Java code is involved. [1] http://github.com/d-widget-toolkit/dwt -- /Jacob Carlborg
Re: VhdCopy v2
On 2017-06-22 17:19, JamesD wrote: I have several utilities I have used in AutoIT, and I'm enjoying converting these to the D language with the DWT GUI. vhdCopy is a GUI wrapper for VboxManage.exe to copy vhd and set GUUID. This version 2 replaces buttons with a GUI menu that is useful as an app template for other such utilities. You can see a screenshot and clone from here: https://github.com/jasc2v8/vhdCopy Nice. You might want to post to the announcement group/forum as well. -- /Jacob Carlborg
Re: Problem building SWTSnippets with D 2.074.x
On 2017-06-02 09:25, Mike James wrote: Hi, I get the following errors when trying to build the swtsnippets with the latest SWT... This is due to a regression in the compiler [1]. Please use 2.073.x until this has been fixed. [1] https://issues.dlang.org/show_bug.cgi?id=17371 -- /Jacob Carlborg
Re: Release dwtlib v1.01
On 2017-04-27 04:52, JamesD wrote: Yes, the dub.sdl in my dwtlib will auto select "linux" or "windows" and choose the dflags and lflags accordingly. https://github.com/jasc2v8/dwtlib The base/java and core/swt modules work well. What other submodules would you want included? I mean that Dub doesn't work that well together with submodules. I'm referring to "base", "org.eclipse.swt.gtk.linux.x86", "org.eclipse.swt.snippets" and "org.eclipse.swt.win32.win32.x86". I just released rdub which would be a great tool for the snippets. https://github.com/jasc2v8/rdub Do you want to take a look at the structure for dwtlib, or do you want me to do a pull request on dwt-tools to show you what I have in mind? I've already looked a bit at dwtlib. I see that you inline the submodules, although the snippets are missing. I'm leaning towards inlining the submodules as well. A pull request would be nice. For this to work I think a pull request for inlining the submodules should be separate from the rest of the changes. -- /Jacob Carlborg
Re: Release dwtlib v1.01
On 2017-04-25 00:07, JamesD wrote: I'm pretty new with D, and I'm not a full-time coder. A learning goal was to see if I could figure out how to create a dub package for DWT. I feel I am well on the way to achieve this goal (32-bit works, need to test 64-bit). I respect your work, as well as the others, in porting DWT from SWT and maintaining it. I don't want to "muck" up your repository. Having said that, I would much prefer this be part of the original github repository. Then, I could retire my dwtlib dub package in favor of the updated github repository. What are your thoughts? I would like to have a Dub package for DWT, but I haven't created one yet because I have not been able to figure out a good way to deal with the submodules or the examples. I guess the submodules could be inlined directly in the main repository. I'm also not sure how the configurations work in Dub. Will the correct configuration be selected automatically based on platform? -- /Jacob Carlborg
Re: build problem with dmd 2.071.2
On 2016-10-09 03:12, goo wrote: hello! I got this problem when i using DWT on lubuntu. [ build.sh ] : dmd app.d -I/home/osboxes/Downloads/build/dwt/imp -J/home/osboxes/Downloads/build/dwt/org.eclipse.swt.gtk.linux.x86/res -L-L/home/osboxes/Downloads/build/dwt/lib \ -L/home/osboxes/Downloads/build/dwt/lib/org.eclipse.swt.gtk.linux.x86 \ -L/home/osboxes/Downloads/build/dwt/lib/dwt-base \ -L-lgtk-x11-2.0 -L-lgdk-x11-2.0 -L-latk-1.0 -L-lgdk_pixbuf-2.0 \ -L-lgthread-2.0 -L-lpangocairo-1.0 -L-lfontconfig -L-lXtst -L-lXext -L-lXrender \ -L-lXinerama -L-lXi -L-lXrandr -L-lXcursor -L-lXcomposite -L-lXdamage -L-lX11 \ -L-lXfixes -L-lpango-1.0 -L-lgobject-2.0 -L-lgmodule-2.0 -L-ldl -L-lglib-2.0 \ -L-lcairo -L-lgnomeui-2 -L-lgnomevfs-2 [ ls ] : $ ls /home/osboxes/Downloads/build/dwt/lib/ dwt-base.a libdwt-base.a liborg.eclipse.swt.gtk.linux.x86.a org.eclipse.swt.gtk.linux.x86.a [ build result ] : /usr/bin/ld: cannot find /home/osboxes/Downloads/build/dwt/lib/org.eclipse.swt.gtk.linux.x86: No such file or directory /usr/bin/ld: cannot find /home/osboxes/Downloads/build/dwt/lib/dwt-base: No such file or directory collect2: error: ld returned 1 exit status I don't think you're passing the libraries correctly to the linker. I recommend you pass the full path directly to DMD instead. -- /Jacob Carlborg
Re: updating DWT
On 16/03/16 09:27, Saša Janiška wrote: Any ETA when you DWT might me updated to 4.x ? Unfortunately no. It takes quite some time to write a tool that converts Java to D. Currently my focus is to rewrite the D grammar that is used by GitHub and TextMate, it's currently broken in some cases. -- /Jacob Carlborg
Re: build problem with 2.0.70
On 16/03/16 09:24, Saša Janiška wrote: OK. Here is another issue: $ dmd main.d -I/home/gour/repos/external/dwt/imp -J/home/gour/repos/external/dwt/org.eclipse.swt.gtk.linux.x86/res -L-L/home/gour/repos/external/dwt/lib -L-l:org.eclipse.swt.gtk.linux.x86 -L-l:dwt-base -L-lgtk-x11-2.0 -L-lgdk-x11-2.0 -L-latk-1.0 -L-lgdk_pixbuf-2.0 -L-lgthread-2.0 -L-lpangocairo-1.0 -L-lfontconfig -L-lXtst -L-lXext -L-lXrender -L-lXinerama -L-lXi -L-lXrandr -L-lXcursor -L-lXcomposite -L-lXdamage -L-lX11 -L-lXfixes -L-lpango-1.0 -L-lgobject-2.0 -L-lgmodule-2.0 -L-ldl -L-lglib-2.0 -L-lcairo -L-lgnomeui-2 /usr/bin/ld: cannot find -l:org.eclipse.swt.gtk.linux.x86 /usr/bin/ld: cannot find -l:dwt-base collect2: error: ld returned 1 exit status --- errorlevel 1 I cloned dwt repo in ~/repos/external/dwt. What's wrong? Currently I don't have access to a Linux machine so I can't try the above myself. But the easiest is to pass the full path of the libraries directly to DMD. It will to the right thing. -- /Jacob Carlborg
Re: build problem with 2.0.70
On 16/03/16 20:48, Saša Janiška wrote: That helped. Thanks. Awesome :) I was able to build several snippets, but still have to decide how much I like DWT code. ;) Hehe. -- /Jacob Carlborg
Re: updating DWT
On 15/03/16 18:17, Saša Janiška wrote: Hello, stil thinking about which GUI to use and today I noticed that according to web site, DWT is based on SWT-3.4, while SWT at upstream is at 4.5,4.6, so I'm interested if porting SWT to DWT is mostly manual work which seems to be disadvantageous and destined to be always a lot behind the upstream or there is plan to somehow make the whole process more automatic and therefore closer to upstream? Yeah, currently it's completely a manual process. I've abandoned the idea of manually updating if favor of an automated process. I'm working on a tool [1] that will automatically translate the Java code to D. [1] https://github.com/d-widget-toolkit/jport/tree/dev -- /Jacob Carlborg
Re: Status of DWT on OS X
On 2016-01-16 08:05, Andrew wrote: I'm looking for a GUI that's cross platform including Windows, Limus, and OS X. From what I can tell, DWT isn't on OS X yet, is that correct? No, DWT isn't on OS X yet. Is DWT is t ready yet, then Are the QT bindings to D stable? I'm not sure that what the status of that is. Please ask in the "learn" forum/newsgroup. -- /Jacob Carlborg
Re: DWT fails to build with DMD 2.069.1
On 2015-11-11 17:17, Mike James wrote: Hi. Is there an updated release of DWT for 2.069? There seems to be a deprecation problem... Should be working now (at least on Windows). -- /Jacob Carlborg
Re: DWT fails to build with DMD 2.068.0
On 2015-08-26 10:59, Mike James wrote: Thanks Jacob, I can confirm the libraries and snippets build no problem. Awesome :) -- /Jacob Carlborg
Re: Error Ocuured while building DWT
On 2015-04-13 11:40, Olagsfark wrote: I'll appreciate if a bugfix could be made sire...i realy would... I'l try the v2.067.0 on a separate drive meanwhile though. Thanks Could you please try the updating DWT and try with the older compiler. I wasn't able to reproduce the problem. -- /Jacob Carlborg
Re: DWT fails to build with DMD 2.067.0
On 2015-03-31 21:09, Mike James wrote: Hi, When I run the build using dub I get the following errors... java\lang\util.d(396): Deprecation: typedef is removed java\lang\util.d(405): Deprecation: typedef is removed java\nonstandard\Locale.d(66): Error: cannot append type string to type wchar[] java\nonstandard\Locale.d(89): Error: template instance java.nonstandard.Locale.caltureNameI error instantiating object.Exception@build.d(251): compile error 0x00404C92 0x00405EA1 0x00403DD4 0x00417D32 0x00417D07 0x00417C1F 0x0041076F 0x751F7C04 in BaseThreadInitThunk 0x76F5B54F in RtlInitializeExceptionChain 0x76F5B51A in RtlInitializeExceptionChain Is there an update for DWT using the latest D compiler? Yes, should work now [1]. [1] https://github.com/d-widget-toolkit/dwt/commit/d43ce0cfec48c499cf43f4002e8916158b175847 -- /Jacob Carlborg
Re: DWT on Mac OS X and with DMD 2
On 2015-03-22 15:41, romain wrote: Hi. I think i might be interested in helping porting from d1 to d2 as far as the Os x version is concerned, even though i don't really know how i could go about that. Any pointer or help would be appreciated. I'm not sure if that's a good idea before the Java - D1 port is finished. If you run in to a bug it's hard to know if it's the Java - D1 port or the D1 - D2 port that caused the bug. I got tried of the manual porting so I'm trying out a new approach to port DWT. That is to create a tool that automatically convert the Java code to D (2). I've created a new project JPort [1], it's written in Scala and uses the Eclipse JDT compiler API's to translate Java to D. It's in a very early stage. If you really do want to port the D1 code to D2 you just need to start rewriting the parts that has changed from D1 to D2. I'm not sure if there's a list of changes between D1 and D2. Looking at the changelog will give you some hints, but it might be too detailed. The -vtls compiler flag will help to show which variables will be but in TLS. The code for the OS X port is available here [2]. The readme in that repository will have some documentation on how to port the Java code to D that is unique to the OS X port. [1] https://github.com/d-widget-toolkit/jport/tree/dev [2] https://github.com/d-widget-toolkit/dwt-mac -- /Jacob Carlborg
Re: Can't Link DWT in Linux 64-bit
On 2014-07-20 01:40, Mike wrote: Interesting! How was the original port from SWT to DWT done? Was some utility used? It's manually ported. There was a try to create a tool [1] to automatically port the code but that required a too big part of the Java standard library to be ported as well. [1] http://dsource.org/projects/tioport -- /Jacob Carlborg
Re: Can't Link DWT in Linux 64-bit
On 2014-07-20 15:52, Jacob Carlborg wrote: It's manually ported. There was a try to create a tool [1] to automatically port the code but that required a too big part of the Java standard library to be ported as well. It might be worth investigation to try and do an automatic port again. I had a look and saw that in Java 6 there's an API for parsing Java. It would be really nice to have completely automatic tool for porting. It could be hard coded for SWT, I think Tioport tried to be usable for other Java projects. -- /Jacob Carlborg
Re: Can't Link DWT in Linux 64-bit
On 21/07/14 03:00, Mike wrote: Well, what's the GUI future of D? Does DWT have a role to play? If we could make the process completely automatic (or nearly automatic) to make it easy to keep up with SWT. And also create a GUI builder then I think DWT is in a very good position. -- /Jacob Carlborg
Re: Can't Link DWT in Linux 64-bit
On 2014-07-21 11:52, Mike wrote: Or, is there a utility out there that can dump Java source to xml or something more consumable by D? Then I might have some hope. No, not that I know of. You might be able to find a Java grammar for some parser generator that could be used. But, as I wrote in the other post, I think semantic analyze is required to do this well enough. -- /Jacob Carlborg
Re: Can't Link DWT in Linux 64-bit
On 2014-07-20 02:46, Mike wrote: What do you mean by native type? I thought the only native types in D were `size_t` and `ptrdiff_t`. What's the actual syntax you use in the OSX port? External C functions that take pointers are declared to take int/long in the Java code. I would prefer that the original type is used. If you're looking for alternative names for `size_t` and `ptrdiff_t` how about: alias native_int = ptrdiff_t; alias native_uint = size_t; Hmm, I don't know. Perhaps ptrdiff_t is good enough. -- /Jacob Carlborg
Re: Can't Link DWT in Linux 64-bit
On 2014-07-19 01:47, Mike wrote:
Well, I haven't tried to build yet, but I have been going through the
source code, and I found something interesting.
I downloaded the swt source code for both Win32 and Win64, and compared
them in WinMerge.
What's interesting is the source code is littered with stuff like this:
File: org/eclipse/swt/widgets/IME.java
Yes, they have a tool (or built step) that replaces int /*long*/ with
long /*int*/ to convert to 64bit.
SWT - Win32
***
LRESULT WM_KILLFOCUS (int /*long*/ wParam, int /*long*/ lParam) {
if (!isInlineEnabled ()) return null;
int /*long*/ hwnd = parent.handle;
int /*long*/ hIMC = OS.ImmGetContext (hwnd);
if (hIMC != 0) {
if (OS.ImmGetOpenStatus (hIMC)) {
OS.ImmNotifyIME (hIMC, OS.NI_COMPOSITIONSTR,
OS.CPS_COMPLETE, 0);
}
OS.ImmReleaseContext (hwnd, hIMC);
}
return null;
}
SWT - Win64
LRESULT WM_KILLFOCUS (long /*int*/ wParam, long /*int*/ lParam) {
if (!isInlineEnabled ()) return null;
long /*int*/ hwnd = parent.handle;
long /*int*/ hIMC = OS.ImmGetContext (hwnd);
if (hIMC != 0) {
if (OS.ImmGetOpenStatus (hIMC)) {
OS.ImmNotifyIME (hIMC, OS.NI_COMPOSITIONSTR,
OS.CPS_COMPLETE, 0);
}
OS.ImmReleaseContext (hwnd, hIMC);
}
return null;
}
DWT
LRESULT WM_KILLFOCUS (int /*long*/ wParam, int /*long*/ lParam) {
if (!isInlineEnabled ()) return null;
auto hwnd = parent.handle;
auto hIMC = OS.ImmGetContext (hwnd);
if (hIMC !is null) {
if (OS.ImmGetOpenStatus (hIMC)) {
OS.ImmNotifyIME (hIMC, OS.NI_COMPOSITIONSTR,
OS.CPS_COMPLETE, 0);
}
OS.ImmReleaseContext (hwnd, hIMC);
}
return null;
}
It appears DWT has modeled any `Handle`s as `void*`, and therefore uses
`auto` whenever possible. I could probably do a search replace for
int /*long*/ or /*long*/ int and replace it with ptrdiff_t and
cover 80% of the necessary changes.
Thoughts?
Ideally I would like that the native type is used, that's what I've done
in the OS X port. But if the existing code uses int /*long*/ then I
would say it's acceptable to use ptrdiff_t. Perhaps we want to come up
with a new name?
Also, could you please answer the following questions for me?
* What version of SWT is the current DWT source code based on?
It's 3.449.0, at least according to this [1].
* How would you like me to submit pull requests? Little-by-little, or
one big whopper?
If possible, smaller changes. But I would prefer DWT to be buildable
in-between pull requests.
* How does one go about testing DWT?
[1]
https://github.com/d-widget-toolkit/org.eclipse.swt.win32.win32.x86/blob/master/src/org/eclipse/swt/internal/Library.d#L31-L41
--
/Jacob Carlborg
Re: Can't Link DWT in Linux 64-bit
On 2014-07-19 01:47, Mike wrote: * How does one go about testing DWT? I don't have a good answer to that. I mostly try the snippets and see that they behave correctly. For some snippets it might not always be easy to see what they're supposed to do or behave. In that case I compare with the the behavior of the Java version. SWT has some kind of tests [1], which probably should be ported at some time. [1] http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/tests/org.eclipse.swt.tests -- /Jacob Carlborg
Re: Can't Link DWT in Linux 64-bit
On 2014-07-13 08:32, Mike wrote: Nevermind, just found out only 32-bit libs are created. Yes, currently DWT only supports 32bit. -- /Jacob Carlborg
Re: Precompiled binaries of DWT for windows?
On 2014-07-01 08:11, pgtkda wrote: Hi, thanks againf or your answer. I navigated to the dmd folder where the rdmd.exe file is. If i type rdmd build base swt i get this Error: Error: cannot read file build.d Failed: ^dmd^ ^-v^ ^-o-^ ^build.d^ ^-I.^ You should navigate to the folder where DWT is located. It should have structure similar to what's seen here [1]. [1] https://github.com/d-widget-toolkit/dwt -- /Jacob Carlborg
Re: Precompiled binaries of DWT for windows?
On 2014-06-27 10:10, pgtkda wrote: Okay, thanks for your detailed answer. What should i do next if i extracted the Win32 zip file? Follow the instructions here [1]. The steps I described above replaces the second step in the linked build instructions. [1] https://github.com/d-widget-toolkit/dwt#building-1 -- /Jacob Carlborg
Re: Attempt at DWT 64 bit port
On 2014-06-24 02:30, ed wrote:
I'm attempting a 64 bit port of DWT and I'd like some feedback on API
changes.
My initial preference was no changes to existing API in order to ease
future updates from SWT proper. But of course that requires casts and I
suspect they will bubble to the surface and be exposed to end-users of DWT.
So now I'm leaning towards API changes of this sort:
/// Extension to String
public int indexOf( in char[] str,
char searched,
int fromIndex ){cast(int)...cast(int)...}
becomes
/// Extension to String
public ptrdiff_t indexOf( in char[] str,
char searched,
ptrdiff_t fromIndex) {...}
This maintains sign compatibility with the original API but may require
some changes to existing code. For example:
---
// Fails 64 bit, works 32 bit
int idx = indexOf(astring, 't', 1);
// Works 64 bit, Fails 32 bit
long idx = indexOf(astring, 't', 1);
// Works 64 bit and 32 bit
auto idx = indexOf(astring, 't', 1);
Does anyone have an alternative preferred approach to portable 32/64 bit
code?
I usually try to think like this, in some kind of priority list:
1. Follow system/native libraries - Example of this is when a system
library uses pointers then the SWT code will use an int/long. In DWT I
would use the original pointer type
2. Follow the original SWT code - We want to make porting of future
versions of SWT as easy as possible
3. Do what's most appropriate in D
In this case I would use size_t because that is the native type D uses
for array indexes. This is what I've done in the Cocoa port, it's ported
to support both 32bit and 64bit form the start.
One possibility is separate code bases for 32 and 64 bit, as per SWT
proper. This is not my preference but I am happy to do it if people feel
it would be better this way.
I think it should be only one code base. SWT is actually only one code
base. They have a tool that converts between 32bit and 64bit. They make
separate releases but the it's only one repository. But D has language
support that will make this easier: alias, version and so on.
--
/Jacob Carlborg
Re: DWT on Mac OS X and with DMD 2
On 14/05/14 12:07, FrankLike wrote: I'v compiled the all snippets examples,the examples are very good,but no enableVisualStyles fuction in DWT,it will help dwt to be nice. You can look at the DFL's enableVisualStyles(). DFL /Application.d // Should be called before creating any controls. // This is typically the first function called in main(). // Does nothing if not supported. void enableVisualStyles() What does it do? -- /Jacob Carlborg
Re: DWT on Mac OS X and with DMD 2
On 2014-05-14 15:03, FrankLike wrote: Ican send a mail to you, ok to email? Sure. -- /Jacob Carlborg
Re: Support for Dub
On 12/05/14 10:33, Sönke Ludwig wrote: Just an idea (although I'd also prefer the first option), subtree merging [1] is a nice alternative to git submodules, which would also work properly for GitHub+DUB. The structure could stay the same and only changes would be required in the main repository. [1]: http://git-scm.com/book/en/Git-Tools-Subtree-Merging Yeah, I'll have to take a look at subtree merging again to refresh my memory. -- /Jacob Carlborg
Support for Dub
For those who haven't noticed Etienne Cimon has created a pull request [1] which adds support for Dub to the DWT project. Currently the DWT project is divided among a couple of git repositories: one of Windows, one for Linux, one for the Java API and one for snippets. These git repositories are included as git submodules in the an additional repository called dwt. The problem is that currently Dub doesn't support git submodules. So I'm thinking about how fit DWT as a Dub package. The current approach by Etienne is to run git submodule update in the Dub preGenerateCommands command. I'm not so sure I like this approach. The question is then: how should we organize DWT to fit as a Dub package? Here are a couple of ideas: * Merge the Windows, Linux and snippets repositories in the main repository. This is how the SWT repository is organized, one single git repository. This would also solve the problem with the duplicated code that exists in the Linux and Windows repositories. This is the platform independent code like the custom widgets. I would still like to have the Java API as a separate git repository, since this is useful without the DWT repository * Create a Dub package of each git repository and remove the git submodules. I don't know how this should be done, perhaps with a main package and has depends on the Linux and Windows packages. This would create extra Dub packages that are not useable on its own I think I like the first one best, but that would require most work as well. Other ideas? [1] https://github.com/d-widget-toolkit/dwt/pull/13 -- /Jacob Carlborg
Re: Building DWT using gdc, Linux Mint 16
On 2014-04-25 18:00, Chris Piker wrote: If I can get DWT built with gdc and then send you a proceedure, would you be interested in testing the instructions on one of your systems? Sure, why not. The easiest would be to get GDMD and RDMD. You can specify the compiler to use when invoking RDMD, you would specify GDMD. You might need to modify the build script to add support for specifying a compiler. -- /Jacob Carlborg
