[Mono-osx] Delphi Prism and all those Cocoa bridges
mh at elitedev.com
Thu Feb 26 12:23:07 EST 2009
> 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
> 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
> 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
> 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
> 3. Monobjc project, references the DLL compiled from 1 and Monobjc
> libraries. Compiles into an EXE and ultimately macpacks into a
> containing the EXE, the DLL, and the NIB file.
makes sense, yes.
> (Will Prism handle the
> 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
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. ;)
More information about the Mono-osx