Jump to page: 1 2 3
Thread overview
GUI program on Mac OS in D?
Dec 06
mrphobby
Dec 08
mrphobby
Dec 08
mrphobby
3 days ago
mrphobby
3 days ago
Jacob Carlborg
3 days ago
Jacob Carlborg
3 days ago
mrphobby
2 days ago
Jacob Carlborg
2 days ago
mrphobby
2 days ago
mrphobby
2 days ago
Adam D. Ruppe
2 days ago
Mengu
2 days ago
mrphobby
2 days ago
Jacob Carlborg
2 days ago
mrphobby
2 days ago
Jacob Carlborg
November 23
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?
November 23
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
November 23
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.
November 23
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
November 24
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...

November 24
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
December 06
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
December 07
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
December 07
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)
December 07
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.
« First   ‹ Prev
1 2 3