I agree Monobjc is very useful. I prefer Monobjc over Cocoa#, which I found
very lacking in support. For me I use Parallels to run Visual Studio and
reference the Monobjc DLLs so that I can use intellisense. Compile there to
work out compile errors. Then in leopard compile again to actually run it.
The power of intellisense far outweighs the inconvenience of a second
compile.
My advice, which is what we are doing, is to create a business logic layer
that is C#. Then on Windows create a native WinForms app and then on Mac
use Interface Builder to create a native look. You will have to write twice
most of the UI code. In theory the majority of logic should be in the
business shared layer anyway.
When working on Mac forget what you know about Windows. Do not try and
mimic the c:\program files or other windows concepts. Embrace the native
infrastructures of each. Trying to be generic or impose one paradigm on the
other will in the end make your app feel like a hack to end users.
Best of luck.
Duane
On Thu, Dec 11, 2008 at 7:07 AM, Andrew Brehm <ajbrehm at gmail.com> wrote:
>> I successfully tries out Monobjc yesterday evening.
>> First of all, a big THANKS to the team who wrote it. It's fantastic! I will
> look into it a lot more.
>> For the moment I managed to get it to use a NIB file (can it use XIB
> files?)
> and display a window and menu. My only problem really was the build
> process.
> I was confused when my program couldn't find the NIB file. Turns out
> Monobjc
> expects to be packaged up into a bundle.
>> My problems in detail:
>> 1. The build process using nant was a bit confusing, at least for me.
> Particularly as nant couldn't find gmcs and I had to set a path to packages
> manually. G-d knows how nant picked up a path to an old version of Mono
> (1.2.6) I didn't have installed any more and why the path wasn't updated
> when I installed Mono 2.0.
>> 2. It took me a while to figure out what to do with the Monobjc nant DLL. I
> know include it in the Visual Studio project and configure the appl.build
> file to use bin/Release as the tools as well as lib directory.
>> 3. Not a problem, but totally worth mentioning: In Visual Studio
> intelligence works very well for Cocoa framework classes!
>> 4. I am trying to figure out if it is possible to create a single code base
> that uses either Winforms or Monobjc depending on compiler switches or,
> ideally, a single binary that uses Winforms or Monobjc depending on where
> it
> is run. For the second case, the bundle thing might be a problem. I wish
> Windows would support bundles.* So far my test program is a C# command line
> utility (officially).
>> 5. Monobjc is not known enough. It should be part of the Mono distribution.
> Please, Novell, talk to the Monobjc team! Everything outside the Mono
> distribution seems very exotic. But Monobjc absolutely deserves to be taken
> seriously as a porting tool. Forget REALbasic, Mono and Monobjc is the way
> to go!
>> *I figure it would be a good idea to install Mono programs on Windows in
> "c:\program files" as bundles and create a shortcut to the
> "Application.app\Contents\Windows\Application.exe" binary. That way the
> bundle could be copied between Mac OS and Windows. In the root of
> "Application.app\" a small Windows program or batch file could create a
> shortcut on the desktop when started.
>> Any thoughts, experiences?
>> --
> View this message in context:
>http://www.nabble.com/Monobjc-thread%2C-please-comment-with-your-experiences-with-Monobjc-tp20954195p20954195.html> Sent from the Mono - OSX mailing list archive at Nabble.com.
>> _______________________________________________
> Mono-osx mailing list
>Mono-osx at lists.ximian.com>http://lists.ximian.com/mailman/listinfo/mono-osx>-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-osx/attachments/20081211/63be4834/attachment.html