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

[Andrew Brehm]

marc hoffman-4 wrote:
> 
> Andrew,
> 
>> Quick question:
>>
>> How does Prism interact with the Monobjc dlls? Where does it get  
>> them? Does
>> it add them to Monobjc-based projects?
> 
> same as C# would - you add them as references to your project
> 

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



marc hoffman-4 wrote:
> 
>> And how does Prism handle projects that are supposed to have some  
>> files in common (non-GUI) and some not (GUI controllers)?
> 
> basically, you'd create three separate projects - a dll with shared  
> code, and then two front-end .exes, one of which would provide WPF or  
> WinForms UI, the other Cocoa with Monobjc. If properly abstracted, the  
> two exes can be pure presentation layer, with all the business logic  
> being in the shared dll.
> 

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. (Will Prism handle the
macpack? How will I add the NIB file to the project? Can Prism pack Mono
into the bundle.app so the program will run on unsuspecting Macs?)

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).

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.



marc hoffman-4 wrote:
> 
> as mentioned before, one thing i got the idea of looking into,  
> yesterday, was to create a sample that uses the MVVM pattern with WPF  
> and Cocoa frontend - using a smart aspect to provide the property  
> binding as needed. lets' see when i'll find the time to look at that ;)
> 
> 

During my test runs I managed to create a single .exe file that checks
whether it is running on Windows or Mac OS X and uses the right GUI for
each. Problem is that it has to be in a bundle.app for the NIB file
connections to work. But on Windows clicking through the bundle folder into
the Resources folder and launching the .exe file there works. The program
will come up as a Winforms program.

Personally, I find those patterns too complicated. I am not exactly a
brilliant programmer. I mostly write linguistics-related programs for my own
use (I am into languages) and am therefore happy if I have access to Unicode
support, regular expressions that work with Unicode (Cocoa doesn't offer
regular expressions and the UNIX regular expressions don't seem to work with
non-ASCII characters), right-to-left writing (Cocoa does that very well, I
hope Windows Forms does too), an easy programming language that doesn't rely
on me to do the memory management, and a way to make those programs run on
Windows and Mac OS (as I use both).

Cocoa lacks the regular expressions and portability but has the best
right-to-left script support. (But it wants me to understand memory
management, which is always a bad move for a programming language.)

.NET has excellent regular expression support and portability, but the GUI
looks terrible on Macs. Until now. Muahahahaha!

Thanks.

-- 
View this message in context: http://www.nabble.com/Delphi-Prism-and-all-those-Cocoa-bridges-tp22180106p22227864.html
Sent from the Mono - OSX mailing list archive at Nabble.com.