www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - GUI program on Mac OS in D?

reply Adam D. Ruppe <destructionator gmail.com> writes:
I know we have the extern(Objective-C) stuff from 
https://wiki.dlang.org/DIP43 now, but do we have existing 
bindings anywhere along the lines of the win32 ones we can just 
import and start calling the operating system functions?

Moreover, I'm not a Mac dev; I've never actually done so much of 
a hello world, so have any of you done like a hello world in 
cocoa using D tutorial or example I can copy/paste to get started?
Nov 23
next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Thursday, 23 November 2017 at 16:06:28 UTC, Adam D. Ruppe 
wrote:
 I know we have the extern(Objective-C) stuff from 
 https://wiki.dlang.org/DIP43 now, but do we have existing 
 bindings anywhere along the lines of the win32 ones we can just 
 import and start calling the operating system functions?

 Moreover, I'm not a Mac dev; I've never actually done so much 
 of a hello world, so have any of you done like a hello world in 
 cocoa using D tutorial or example I can copy/paste to get 
 started?
Perhaps https://github.com/p0nce/DerelictCocoa
Nov 23
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 23 November 2017 at 16:14:50 UTC, Guillaume Piolat 
wrote:
 Perhaps https://github.com/p0nce/DerelictCocoa
Well, that would be one option, though I was hoping to avoid the extern(C) runtime stuff and dynamic loading - ideally, I want something with the extern(Objective-C) stuff for static binding.
Nov 23
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2017-11-23 17:06, Adam D. Ruppe wrote:
 I know we have the extern(Objective-C) stuff from 
 https://wiki.dlang.org/DIP43 now, but do we have existing bindings 
 anywhere along the lines of the win32 ones we can just import and start 
 calling the operating system functions?
Not as far as I know. Only a small part of what's in DIP43 is merged upstream in DMD, that is calling instance methods. DStep can generate bindings for Objective-C code but it will generate bindings for the full implementation of DIP43, so some things will not work with the official DMD. Back in the days when I announced 64bit version of DIP43 some guy started using it and seems to have a fairly complete set of bindings [1]. But again, those are for the full implementation of DIP43.
 Moreover, I'm not a Mac dev; I've never actually done so much of a hello 
 world, so have any of you done like a hello world in cocoa using D 
 tutorial or example I can copy/paste to get started?
I have a simple example [2] of an application that shows a window with a WebKit view, i.e. and embedded browser. This works with the upstream DMD and LDC compilers. It basically only contains bindings for what I needed for that sample application. As you'll see there you need to use some parts of the Objective-C runtime to create class instances and subclasses. Also some gymnastics are required for class/static methods. Note that this example is not a traditional Mac application, it was designed to not use .nib files (GUI files) and be embedded as a library inside another application. If you want to give this a try, I recommend finding some Objective-C/Swift hello world examples online, combine that with my sample application [2] and the official documentation [3] for interfacing with Objective-C. You can use DStep to generate bindings and do some post-processing to remove/change what doesn't compile today using DMD. If you have any questions, please let me know. [1] https://github.com/DiveFramework/DiveFramework [2] https://github.com/jacob-carlborg/d_webkit_test [3] https://dlang.org/spec/objc_interface.html -- /Jacob Carlborg
Nov 23
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 23 November 2017 at 17:28:43 UTC, Jacob Carlborg 
wrote:
 I have a simple example [2] of an application that shows a 
 window with a WebKit view, i.e. and embedded browser.
Thanks, this gets me started. Do you happen to know if there is anything like "pragma(lib)" for the -framework argument? (I don't use dub, so I took your config there to make my own command line, but it would be nice if I didn't have to specify the framework. I use pragma(lib) on Windows and Linux so infer it automatically.)
 As you'll see there you need to use some parts of the 
 Objective-C runtime to create class instances and subclasses. 
 Also some gymnastics are required for class/static methods.
Yes, indeed. The old mac code I had here used all the extern(C) calls (it was contributed to me by a forum user, I didn't write it myself, but did look at it), so some of that is actually familiar. So my plan here is to get more of my libs working on Mac: update the old simpledisplay.d port so it runs on the native api again (currently it just uses XQuartz), then make my simpleaudio.d use OpenAL which I hear has been included with the mac os for some time, then maybe even move on to minigui.d and have it use some native controls too, if reasonable. But the first step is just creating a basic window and your code worked, so thanks, I am on the path now...
Nov 24
parent reply Jacob Carlborg <doob me.com> writes:
On 2017-11-24 16:09, Adam D. Ruppe wrote:

 Thanks, this gets me started.
 
 Do you happen to know if there is anything like "pragma(lib)" for the 
 -framework argument? (I don't use dub, so I took your config there to 
 make my own command line, but it would be nice if I didn't have to 
 specify the framework. I use pragma(lib) on Windows and Linux so infer 
 it automatically.)
There's not [1].
 So my plan here is to get more of my libs working on Mac: update the old 
 simpledisplay.d port so it runs on the native api again (currently it 
 just uses XQuartz),
I think you should start by deciding if you want to use any .nib files or not. If you do use .nib files there is quite a lot of code that can be removed from my sample application.
 then make my simpleaudio.d use OpenAL which I hear 
 has been included with the mac os for some time
Yes, it's included. Apple has several audio frameworks [2], where OpenAL is one of them, for different purposes and different levels.
 , then maybe even move on 
 to minigui.d and have it use some native controls too, if reasonable
 But the first step is just creating a basic window and your code worked, 
 so thanks, I am on the path now...
BTW, the following line [3] of the Dub file will embed the Info.plist file in the executable, which can be handy if you don't want to use application bundles. The Info.plist file is not always necessary, I think my sample application will work without it, but for some things is necessary. I also have a Dockerfile [4] with a cross-compiler setup that targets macOS. You should also know that there's a bug in DMD, which I haven't manged to fix, that occurs when returning certain structs from Objective-C methods. I'm pretty sure if works correctly in LDC, since it's using the LLVM backend that already knows about Objective-C. Finally, since you're using D you'll not have ARC (Automatic Reference Counting) which these days are preformed by the Objective-C and Swift compilers. You'll need to resort to traditional release/retain calls where appropriate. I have not included those calls in my sample application. If you decide to use DStep, please file bugs and let me know how it works. It has not been battle tested for Objective-C code. [1] https://issues.dlang.org/show_bug.cgi?id=2968 [2] https://developer.apple.com/library/content/documentation/MusicAudio/Conceptual/CoreAudioOverview/CoreAudioFrameworks/CoreAudioFrameworks.html [3] https://github.com/jacob-carlborg/d_webkit_test/blob/master/dub.sdl#L12 [4] https://github.com/jacob-carlborg/docker-ldc-darwin/blob/master/Dockerfile -- /Jacob Carlborg
Nov 24
parent reply mrphobby <mrp spinrock.net> writes:
On Friday, 24 November 2017 at 15:56:21 UTC, Jacob Carlborg wrote:
 BTW, the following line [3] of the Dub file will embed the 
 Info.plist file in the executable, which can be handy if you 
 don't want to use application bundles. The Info.plist file is 
 not always necessary, I think my sample application will work 
 without it, but for some things is necessary.

 I also have a Dockerfile [4] with a cross-compiler setup that 
 targets macOS.

 You should also know that there's a bug in DMD, which I haven't 
 manged to fix, that occurs when returning certain structs from 
 Objective-C methods. I'm pretty sure if works correctly in LDC, 
 since it's using the LLVM backend that already knows about 
 Objective-C.

 Finally, since you're using D you'll not have ARC (Automatic 
 Reference Counting) which these days are preformed by the 
 Objective-C and Swift compilers. You'll need to resort to 
 traditional release/retain calls where appropriate. I have not 
 included those calls in my sample application.
I'm also interested in making native macOS apps. I have a lot of experience in Objective-C but I'm new at D. I'm a bit confused at what documentation to look at. In [1] I get the impression that support for creating instances is very rudimentary, but in [2] it looks much better with constructors mapped with selector. What level of support is there in the latest DMD compiler? Also, is there any support for creating macOS application bundles? [1] https://dlang.org/spec/objc_interface.html [2] https://wiki.dlang.org/DIP43
Dec 06
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2017-12-06 17:50, mrphobby wrote:

 I'm also interested in making native macOS apps. I have a lot of 
 experience in Objective-C but I'm new at D. I'm a bit confused at what 
 documentation to look at. In [1] I get the impression that support for 
 creating instances is very rudimentary, but in [2] it looks much better 
 with constructors mapped with  selector. What level of support is there 
 in the latest DMD compiler?
The latest DMD compiler only supports what's in the official documentation, i.e. [1]. What's documented in DIP43 [2] (except anything marked with "unimplemented") is what's been implemented in one of my forks. I'm working on adding what's in my fork piece by piece to upstream.
 Also, is there any support for creating macOS application bundles?
No, there are currently no plans for that. As far as I understand the Objective-C compiler will not to this either. When using Objective-C I think either Xcode or some other tool is creating the bundle. Note that a bundle is just a directory with a specific structure, which can easily be created without any special tools. [1] https://dlang.org/spec/objc_interface.html [2] https://wiki.dlang.org/DIP43 -- /Jacob Carlborg
Dec 07
parent mrphobby <mrp spinrock.net> writes:
On Thursday, 7 December 2017 at 09:39:45 UTC, Jacob Carlborg 
wrote:
 The latest DMD compiler only supports what's in the official 
 documentation, i.e. [1]. What's documented in DIP43 [2] (except 
 anything marked with "unimplemented") is what's been 
 implemented in one of my forks. I'm working on adding what's in 
 my fork piece by piece to upstream.
Ok thanks for clearing that up! Your work looks really appealing. Hope it gets into the official compiler soon.
Dec 08
prev sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Wednesday, 6 December 2017 at 16:50:10 UTC, mrphobby wrote:
 Also, is there any support for creating macOS application 
 bundles?

 [1] https://dlang.org/spec/objc_interface.html
 [2] https://wiki.dlang.org/DIP43
You can easily make a DUB frontend to do that, for example https://github.com/AuburnSounds/Dplug/tree/master/tools/dplug-build (you'll find some code that generates Mac bundles in there, with pretty minimal Info.plist)
Dec 07
parent reply Guillaume Piolat <first.last gmail.com> writes:
On Thursday, 7 December 2017 at 12:18:21 UTC, Guillaume Piolat 
wrote:
 You can easily make a DUB frontend to do that, for example 
 https://github.com/AuburnSounds/Dplug/tree/master/tools/dplug-build
And it might be cleaner to do this as a post-build step.
Dec 07
parent mrphobby <mrp spinrock.net> writes:
On Thursday, 7 December 2017 at 12:27:36 UTC, Guillaume Piolat 
wrote:
 On Thursday, 7 December 2017 at 12:18:21 UTC, Guillaume Piolat 
 wrote:
 You can easily make a DUB frontend to do that, for example 
 https://github.com/AuburnSounds/Dplug/tree/master/tools/dplug-build
And it might be cleaner to do this as a post-build step.
Thanks, I'll have a look at that.
Dec 08