[Mono-osx] Delphi Prism and all those Cocoa bridges

[marc hoffman]

Andrew,

> Yes, but I mean when Prism compiles the project using Mono and  
> macpacks it,
> will it copy those DLLs into the bundle.app?

yes. all Copy-Local references will be copied into the bundle. there's  
also a special Build Action type to specify other resources to be  
copied.

> That's a good idea. In my previous experiments I always tried to make
> everything one project. But that actually made it harder to keep GUI  
> code
> and business logic ("model") separate.
>
> On the Mac side having a DLL and an EXE is not a big problem as both  
> will be
> in the bundle anyway. And Windows expects an installer, I suppose,  
> where I
> can add the DLL (which I can reference from the Bin/Release folder  
> of the
> DLL project, I suppose.
>
> So to avoid confusion, it would work like this:
>
> 1. DLL project, NO GUI code, just a bunch of classes and methods for  
> model
> stuff. References whatever that code needs.
>
> 2. Winforms project, references the DLL compiled from 1. Compiles  
> into an
> EXE that comes with that DLL. Must create installer that contains  
> EXE and
> DLL.
>
> 3. Monobjc project, references the DLL compiled from 1 and Monobjc
> libraries. Compiles into an EXE and ultimately macpacks into a  
> bundle.app
> containing the EXE, the DLL, and the NIB file.

makes sense, yes.

> (Will Prism handle the
> macpack?

yes.

> How will I add the NIB file to the project?

the first NIB is there when you create the project from template. we  
dont currently have a template for additional NIBs (so youll need to  
add those manually, for now), but we'll address that

> Can Prism pack Mono
> into the bundle.app so the program will run on unsuspecting Macs?)

not currently/automatically no. you'll need to do that manually using  
the bundling instructions on the mono site.

> The only downside is that using that method I won't have a single  
> EXE with
> no DLL requirement that will run on both platforms (and look  
> terrible on the
> Mac).

you could always just add the .pas source files for the shared code to  
both the .exe and the Mac DLL *or to both exes). not "the .NET way" to  
do things, but feasible.

> But I can add a fourth project if I want to support Linux and Gtk#.
>
> This will be more work on the GUI side than using REALbasic, but  
> will give
> me Cocoa (REALbasic uses Carbon), the power of the .NET framework  
> and (on
> the Mac) access to Cocoa APIs, and through the CLR a way to run the
> resulting binaries on even more platforms than supported by REALbasic
> (Windows x86, Mac OS X, Linux x86). Plus the extra work for the GUI
> translates into better-looking GUIs.
>
> I think it's a good trade-off.

indeed. ding proper UI for each platform will always be more work, but  
it'll be worth it, for having a Mac app that doesn't suck. ;)

yours,
marc