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 13:18, Sai wrote: Yup, that's what I thought, that this forum is not exclusive for DWT anymore, but is available for all Gui libs. Anyway I did repost my question in GtkD GH issues. For most exposure I recommend the learn forum or, as you did, post to GitHub. -- /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: Release dwtlib v1.01
On 2017-04-24 04:06, JamesD wrote: dwtlib - DUB package for the D Widget Toolkit https://code.dlang.org/packages/dwtlib DWT is a library for creating cross-platform GUI applications. It's a port of the SWT Java library from Eclipse. *Status* WORKING Tested on: - Windows 10 Home - Ubuntu 16.04 LTS 32-bit - DMD32 v2.073.0 - DUB v1.2.010 TODO: - Test current versions of DMD/DUB (had probs with DMD v2.074) - Test 64-bit Is this something you plan to contribute back to the original repository? -- /Jacob Carlborg
Re: eclipse4 application model and dwt
On 2017-04-10 21:40, Jay Norwood wrote: I recently worked on an application using the eclipse4 application model. It includes an extension/rework of the swt layout features. The layout is tied to an emf model. It supports some nice features, such as ... 1. Persistence/recall of multi-window/ multi-monitor layouts 2. Simple runtime replication/duplication of complex layouts by duplicating snippets of the model. 3. Hierarchical gui event notifications, so that, for example, replicated layouts have their own local contexts for gui events. 4. Sharing of visual layout parts and their associated classes among multiple "perspective" layouts. Is there a D gui framework that already provides a similar level of layout/replication capabilities? No, not that I'm aware of. Bug you might want to ask in the "learn" newsgroup/forum to get some more visibility of your post. I know that there are other GUI framework. -- /Jacob Carlborg
Re: DWT Windows Load Icon from File/Program/Resource
On 2017-02-25 09:45, JamesD wrote:
I'm a hobbyist and new to the D language. With a lot of help from
various online resources, I finally figured out how to load an icon from:
1. A file "icon.ico" (this was easy)
2. A Program extension from the Windows registry, e.g. "*.inf" (harder)
3. A linked resource from the exe itsself (very hard)
I learned how to add an icon to the exe with a compiled Resource file.
Now I can load this embedded icon as the shell icon.
And I don't have to distribute a separate ico file with my exe.
I added a couple of simple bat files to compile with either dmd or dub.
This work can be found at:
https://github.com/jasc2v8/dwt-support/tree/master/windows/example-load-icon
I hope this helps another newbie like me.
Constructive feedback is welcome.
In D it's very simple to embed resources in the executable at compile
time using string imports:
immutable data = cast(immutable(uyte[]) import("foo.ico");
Compile by adding the -J flag to point to the directory where the icon
files are located:
dmd main.d -J./resources
Then I'm pretty sure there's a an API that takes a byte array and
returns an image of some sort.
--
/Jacob Carlborg
Re: DWT Support Docs for Windows
On 2017-02-20 05:25, JamesD wrote:
Thank you for your constructive feedback!
Correct, only 2 build targets in DDT at this time;
(default)
(default):unittest
I agree that hijacking unittest is not the best approach. What I am
doing now is to edit the (default) build target as follows.
Original: ${DUB_TOOL_PATH} build
Modified: ${DUB_TOOL_PATH} build -b=release
I leave the (default):unittest unmodified as follows.
Original: ${DUB_TOOL_PATH} build -b unittest
Sounds reasonable. Can you add additional build targets, one for the
release?
Thanks for your suggestions about updating my docs. I plan to as I learn
and time permitting.
Yes, DDT is indeed leveraging DUB to do the builds. Obviously, DDT will
allow me to crate a batch file or whatever for other build methods, but
DUB is convenient for linking with the DWT library.
I'm not saying that you would not use Dub to do the build, just invoke
it differently, as you done above.
--
/Jacob Carlborg
Re: DWT Support Docs for Windows
On 2017-02-10 03:11, JamesD wrote: The Eclipse DDT plugin creates a shell dub.json. My doc "Config DWT GUI for Eclipse DDT on Windows" shows how to edit this dub.json to reference the DWT imports and libraries. The Eclipse DDT plugin basically executes the "dub build -b" command. By default, it is the debug version. Also by default, dub reads the dub.json file so the app.d can link to the DWT libraries. The user can certainly execute the commands manually or in a windows batch file - I'm working on another doc for that process as well. Claiming that there are only two build targets, default and unittest, is not correct. Perhaps it's only possible to build these two targets from DDT. I don't think it's the right approach to hijack the "unittest" target to build a release build. If the issue is that DDT can only build two targets than that should: A. be fixed, B. be properly explained in your docs and that it's possible to build the release target from the command line. Since DDT, I assume, is leveraging Dub to do all the dependency tracking, configuration and building it's very simple to build in the same way as DDT does on the command line. -- /Jacob Carlborg
Re: DWT Support Docs for Windows
On 2017-02-07 22:48, JamesD wrote: I'm a programming hobbyist and I'm new to the D language. I've recently struggled to get a GUI working on Windows. I finally made some progress, and have created a few docs that I hope will help others. Constructive feedback is welcome. The following are on https://github.com/jasc2v8/dwt-support under \doc: 1. Why use the DWT GUI for the D Language 2. Config DWT GUI for Eclipse DDT on Windows 3. Build DWT 64 bit on Windows That's great. A few comments: * Since DMD 2.073.0 (I believe) Dub is included * I don't know how the dub.json file that DDT creates looks like. But usually with Dub you build a release build with the following command: "dub build -b release". See "dub build -h" for more information, there are some other build types available as well * About the disadvantages, in my opinion, native widgets is an advantage. I guess there are two kinds of people, those that like native widgets and those who don't -- /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: Building DWT
On 2016-04-08 02:08, chrisalex wrote: I followed the instructions on the git readme, I copied the res and imp folders to /usr/include/d/, and I added these dflags to dub "dflags" : ["-J/usr/include/d/res", "-I/usr/include/d/imp"] However, when I try to compile anything using DWT, I get these undefined reference errors (this is just trying to import it) .dub/build/application-debug-linux.posix-x86_64-dmd_2070-4CF3803ADC5BBCCDFE1B352AFA5EC835/dwttest.o:(.rodata+0x98): undefined reference to `_D3org7eclipse3swt7widgets7Display12__ModuleInfoZ' --- errorlevel 1 .dub/build/application-debug-linux.posix-x86_64-dmd_2070-4CF3803ADC5BBCCDFE1B352AFA5EC835/dwttest.o:(.rodata+0xa0): undefined reference to `_D3org7eclipse3swt7widgets5Shell12__ModuleInfoZ' I'm thinking that I need the static libraries for the dependencies listed on the readme, but I run into errors trying to build those packages in arch linux because of my graphics drivers, and there are a hefty amount of them. Any insight would be appreciated, thanks. How do you build your application that uses DWT? -- /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: build problem with 2.0.70
On 15/03/16 11:01, Saša Janiška wrote: Saša Janiška writes: Any hint? It looks it's the following: https://github.com/d-widget-toolkit/dwt/issues/22 since it works when I do not specify '-m64' flag? Seems to be the same issue. -- /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: Unable to link DWT build
On 2015-11-20 00:10, Paul D Anderson wrote: Downloaded DWT win32 and built it okay, but when I try to compile and link the "hello world" program I get link errors. I don't know enough about the win32 linker to know what the problem is. The most serious error is org.eclipse.swt.win32.win32.x86.lib 'Error 43: Not a Valid Library File'. I'm guessing this is a mismatch between object formats. By default, DMD will create libraries in the OMF format, for 32bit platforms. For 64bit it will create libraries in the COFF format. The OMF format requires the Optlink linker, shipped with DMD. COFF requires the linker from the Microsoft tool chain. It's also possible to output libraries in the COFF format for 32bit platforms, using the -m32mscoff flag. I'm also having trouble specifying the lib and base directories. I get 'File not found lib.lib'. Ditto for base.lib. The link command line I'm using is LINK main, lib +"org.eclipse.swt.win32.win32.x86.lib" +"dwt-base.lib" /SUBSYSTEM:WINDOWS:4.0" Where have I gone wrong? I'm not very familiar with Windows. That last part of the question looks a generic Windows question which is not specific to DWT. I recommend asking in the "learn" forum/group or you could look have a at the build script for DWT [1], which successfully builds and links the snippets. Note also that the command for Optlink was renamed recently from "link" to "optlink" (I think), to avoid conflicting with the Microsoft linker. I recommend using the compiler when linking. [1] https://github.com/d-widget-toolkit/dwt/blob/master/build.d -- /Jacob Carlborg
Re: DWT fails to build with DMD 2.069.1
On 2015-11-17 14:57, Mike James wrote: Thanks. Libraries and snippets (apart from snippet 288 - std.stream depreacation) build ok. Sorry about that. I forgot to update the snippets submodule, please try now. -- /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.069.1
On 2015-11-12 15:43, xky wrote: Oooh... sad news. Pull requests are welcome ;) Otherwise I might have time during the weekend. -- /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... No, not yet. -- /Jacob Carlborg
Re: DWT license
On 2015-11-11 05:43, Carl Sturtivant wrote: Hello, under what license is DWT distributed? Eclipse Public License (EPL). -- /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: DWT fails to build with DMD 2.068.0
On 2015-08-25 18:23, Mike James wrote: Hi Jacob, when I try to build the latest I get this... Sorry, I forgot to update the submodules, please try now. -- /Jacob Carlborg
Re: DWT fails to build with DMD 2.068.0
On 2015-08-24 09:10, Mike James wrote: Bump! :-) Ah, sorry, completely forgot about this post. But the good news is that it's already merged :) -- /Jacob Carlborg
Re: DWT fails to build with DMD 2.068.0
On 2015-08-11 10:23, Mike James wrote: Is there an updated release for DWT - it fails to build with the latest version of DMD - mainly casting errors... There's an open pull request for adding support for 2.068.0. I'll take a look at it as soon as possible. -- /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: Error Ocuured while building DWT
On 2015-04-13 09:44, Olagsfark wrote: Thanks sire..i use DMD version 2.066.0 Probably the changes we made to make it compatible with 2.067.0. It should work with older versions as well, I'll take a look. Could try with 2.067.0 as well? -- /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: First round of changes for 64-bit port: base
On 2014-07-26 02:59, Mike wrote: Please take a moment to review my changes for the `base` repository. It compiles in DMD 2.065 Arch Linux 64-bit with either -m32 or -m64. It's my understanding that the Java classes all use `int` for lengths, indexes, etc... so my approach was to simply cast the underlying D `long`s to `int`s so the Java API remains the same. I would like to know if I'm on the right track, so please take a moment to give my changes a peer review. https://github.com/JinShil/base/commits/master Sorry for taking so long. I made a quick review and added some comments. Except for these, it looks pretty good. Please use "rebase", I don't want any merge commits. -- /Jacob Carlborg
Re: First round of changes for 64-bit port: base
On 2014-07-26 02:59, Mike wrote: Please take a moment to review my changes for the `base` repository. It compiles in DMD 2.065 Arch Linux 64-bit with either -m32 or -m64. It's my understanding that the Java classes all use `int` for lengths, indexes, etc... so my approach was to simply cast the underlying D `long`s to `int`s so the Java API remains the same. I would like to know if I'm on the right track, so please take a moment to give my changes a peer review. https://github.com/JinShil/base/commits/master I don't have time right now but I will do a proper review. -- /Jacob Carlborg
Re: Can't Link DWT in Linux 64-bit
On 2014-07-26 15:49, Mike wrote: I've been thinking more about this. If you could use this scala code to output the java code is something more consumable by D, it may be easier for others in this community to help build on it. I realize there will need to be semantic analysis, but as long the syntax is appropriately annotated as methods, parameters, types, expressions, etc... and maintains lexical order, D could do the semantic analysis. I'm thinking something like JaML: http://www2.informatik.uni-wuerzburg.de/uploads/media/jaml_technical_report.pdf I can just as easy output it directly to D as XML. Or is there are tool that can do that already. Is that what JaML is? -- /Jacob Carlborg
Re: Can't Link DWT in Linux 64-bit
On 2014-07-21 11:35, Mike wrote: Well, I've never written any Java code before, and I'm not looking forward to learning yet another language. Is it possible to utilize the java parser from D? Just for the record, I started a project to do this [1]. It's very simple so far. But the basic structure is there. It sets up the compiler, starts the parsing and so on. Just start adding visitor methods like this [2] for different language constructs. [1] https://github.com/d-widget-toolkit/jport [2] https://github.com/d-widget-toolkit/jport/blob/master/src/dwt/jport/analyzers/CodeAnalyzerTreeVisitor.scala#L14 -- /Jacob Carlborg
Re: Distributing Windows Static Libraries in DWT
On 25/07/14 02:11, Mike wrote: Walter has informed me that Digital Mars has a separate agreement with Microsoft permitting the redistribution of the static libs here (https://github.com/d-widget-toolkit/org.eclipse.swt.win32.win32.x86/tree/master/lib) with DMD. That agreement does not transfer to DWT. It appears the static libs are only used when building the snippets, however. I think it would be best to remove those .lib files from the Github repository, modify the build script, and update the instructions. I'll try to get it done in the next couple of weeks, but anyone else is also welcome to help. Ok, thanks for the heads up. A pull request would be awesome. -- /Jacob Carlborg
Re: 64-bit build: Librarian Error
On 24/07/14 20:24, Mike wrote: Compiles fine on Linux 64-bit, though. Could this be a bug in DMD's lib.exe on Windows? As far as I know, you shouldn't be using the DMD tool chain at all when building 64bit on Windows. Except for the D compiler. -- /Jacob Carlborg
Re: 64-bit Windows Static Libs
On 2014-07-22 14:57, Mike wrote: In order to do the 64-bit port, it looks like I'm going to need the 64-bit versions of the static libs here: https://github.com/d-widget-toolkit/org.eclipse.swt.win32.win32.x86/tree/master/lib It looks like I already have both 32-bit and 64-bit versions of the files on my computer. But I have so many different versions. DMD also distributes some of these files. Where is the official source of these files, and how would I know which versions are needed? Is there a redistributable from Microsoft? Actually I have no idea. I very little development on Windows. You could try asking in some of the more general newsgroups/forums here, "learn" or "D". -- /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-21 11:35, Mike wrote: Well, I've never written any Java code before, and I'm not looking forward to learning yet another language. Is it possible to utilize the java parser from D? In theory it should be possible to access via JNI (Java Native Interface), but that's very cumbersome and it would be easier to write the tool in Java, or any other language that runs on the JVM (Scala, Ruby and so on). I'm thinking I should probably just get the 64-bit port done for now, but if you can think of a way to write the porting utility in D I'll consider giving it a try. Possibly if there's a parser wirtten in C. But I'm not sure if a parser is enough, I think a full front end is needed, including the semantic analyzer. -- /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 21/07/14 03:00, Mike wrote: Well, what's the GUI future of D? Does DWT have a role to play? I think so. But not so many others do. They either want to use Qt, GTK or create a completely new framework. * GTK - doesn't native drawing operations. Requires separate download * Qt - written in C++, hard to interface with. I don't think it uses native drawing on all platforms. Requires separate download * Completely new framework - huge undertaking, will take a massive amount of time and resources -- /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 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 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: * 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-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: Attempt at DWT 64 bit port
On 2014-07-19 00:23, Mike wrote: Where can one obtain this tool and, hopefully, its source code? Hmm, it might be this one [1]. Source code is somewhere here [2]. As far as I remember it didn't really do any interesting. Mostly converting between "long" and "int". [1] http://www.eclipse.org/swt/jnigen.php [2] http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/bundles/org.eclipse.swt.tools -- /Jacob Carlborg
Re: Can't Link DWT in Linux 64-bit
On 2014-07-14 18:57, Mike wrote: I'm using Arch Linux 64, and the multilibs are missing libgnomeui-2. What are your future plans for DWT? Are you still interested in investing into it or are you yielding to gtkd/qtd/etc..? I'm currently not working on DWT. When I will do that again it will be on the OS X port. I'm still trying to keep it up to date with the latest version of DMD, reviewing pull requests and helping out here. I really like the library and was able to pick it up very quickly. If you're interested in putting more into it, what can I do to help? Can you gude me through the changes necessarry to port it to 64-bit? Absolutely. First, there are someone else that is already working on a 64bit port, if I understand it correctly [1]. Perhaps you could collaborate. As for the guidance. I think it's easiest to just try and compile it for 64bit and see what errors you get. Then I can help with more specific problems that you encounter. Start by removing the "-m32" flags in build.d [2], which forces it to compile for 32bit. Then I would guess most errors will be for types declared as "int" when they should be declared as "size_t" or "ptrdiff_t". I have no idea how the GTK and Gnome interfaces work, if they are different on 64bit. I didn't write the original code for DWT. [1] http://forum.dlang.org/thread/cpmhhmslzyvtpkzsg...@forum.dlang.org [2] https://github.com/d-widget-toolkit/dwt/blob/master/build.d -- /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 14:45, pgtkda wrote: Okay, i think i got the PATH variable. But now, i get this: Hmm, that's look strange. I'll take a look at this and see what I can find. -- /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-07-01 08:29, pgtkda wrote: Okay, i created the missing folders. But now if i type this in my console: C:\Program Files (x86)\dmd.2.063.2\dmd2\windows\bin>rdmd build base swt (in C:\Program Files (x86)\dmd.2.063.2\dmd2\windows\bin) Building dwt-base workdir=>C:\Program Files (x86)\dmd.2.063.2\dmd2\windows\bin\base\src dmd.exe @C:\Program Files (x86)\dmd.2.063.2\dmd2\windows\bin\rsp The command "dmd.exe" is either misspelled or could not be found. As I answered to your previous post, you run that command in directory where DWT is located. You also need to be able to access "rdmd" and "dmd" from the command line, anywhere. I don't know how you have installed "dmd" but I looks like it's not added to your PATH environment variable. -- /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: Precompiled binaries of DWT for windows?
On 2014-06-27 09:51, pgtkda wrote: Not so easy for me. Where do i have to type this? $ git clone --recursive git://github.com/d-widget-toolkit/dwt.git In a terminal/cmd (btw, you don't type $, that just an indication it should be typed in a terminal). Of course, this requires you to have "git" installed. Which I would recommend if you're doing any development with D. Alternatively you can download a zip of the sources: 1. Download the DWT sources [1] 2. Extract the zip file 3. Download the DWT Win32 sources [2] 4. Extract the Win32 zip file into "dwt\org.eclipse.swt.win32.win32.x86", where "dwt" is the path you extracted the DWT source code to [1] https://github.com/d-widget-toolkit/dwt/archive/master.zip [2] https://github.com/d-widget-toolkit/org.eclipse.swt.win32.win32.x86/archive/master.zip -- /Jacob Carlborg
Re: Precompiled binaries of DWT for windows?
On 2014-06-26 10:19, pgtkda wrote: Are there any precompiled binaries for windows? Unfortunately no, there are no pre-compiled binaries. But it's very easy to build yourself, just follow the build instructions [1]. [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 15/05/14 05:53, FrankLike wrote: Can you tell me your email? Thank you. You should be able to see here somewhere. -- /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: 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-12 16:24, FrankLike wrote: Good job. Thanks :) -- /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: Widget Arguements
On 05/05/14 08:39, Jack wrote: Nvm I just found that I should include org.eclipse.swt.SWT. Sorry for the stupid question. No problem. -- /Jacob Carlborg
Re: Widget Arguements
On 05/05/14 06:32, Jack wrote: I'm using the SWT API to learn DWT and saw one thing that I didn't particularly understand. Basically in the SWT Documentations the syntax goes like this: Menu menu = new Menu(shell, SWT.BAR); While DWT requires an integer for the second arguement. auto menu = new Menu(shell, 1); Yes, but SWT.BAR is an integer so that should work. The API is the same in Java. I'm gonna ask, where can I find some documentation or any sort of hint to know what integer corresponds to what component in DWT. Thank you. There really is no API documentation for DWT since it's using the same API as SWT, any documentation for SWT should be applicable. -- /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
Re: Building DWT using gdc, Linux Mint 16
On 25/04/14 07:30, Chris Piker wrote: I've not been able to find instructions on building DWT using gdc. The gdc package for Linux Mint 16 didn't come with an rdmd script (or gdmd for that matter either). If someone on the list could point me towards the installation instructions for DWT using gdc I'd really appreciate it. Hmm, I never actually tried to build DWT using GDC. Is there another package that contains RDMD and/or GDMD? If there's a package for DMD, that might contain RDMD. Otherwise I suggest you talk with the GDC developers or the ones that packaged GDC for Mint. -- /Jacob Carlborg
