[Mono-osx] Monobjc thread, please comment with your experiences with Monobjc

[Andrew Brehm]

I am somewhat familiar with Objective-C and Cocoa and have written a few
small applications for Mac OS. The only major problems I have with
Objective-C is lack of portability and apparently there is no regular
expression class (and no regex functions for unicode strings either).

I use VMware and Vista 64. Otherwise the process is like yours. I described
the general idea for Cocoa# here:
http://www.netneurotic.net/DNET/StupidWordCounter/

Now I am trying to figure out how to adapt it for Monobjc.

I am thinking the following:

1. Reference Monoobjc DLLs and the Monoobjc nant DLL.

2. Build in Visual Studio. This will copy the DLLs into bin\Release.

3. Copy to Mac OS, create a directory something.lproj for NIB files.

4. Should I create an Xcode project to keep track of files? Would that help
with the *.lproj folder?

5. Modify the appl.build file from the SimpleCocoaApp sample. Change all
relevant paths to point to bin\Release.

6. Build using nant. (Can this be added to Xcode as a build step?)

7. Find Application.app bundle in bin/Release folder.

8. Add Winforms version of application to Application.app/Contents/Windows.

9. Arrange for a shortcut to the binary in /Contents/Windows on the Windows
desktop after installation on Windows. Application.app should be installed
by copying the bundle (folder) into /Applications on Mac OS and "C:\Program
Files" on Windows.




duanew wrote:
> 
> 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
>>
> 
> _______________________________________________
> Mono-osx mailing list
> Mono-osx at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-osx
> 
> 

-- 
View this message in context: http://www.nabble.com/Monobjc-thread%2C-please-comment-with-your-experiences-with-Monobjc-tp20954195p20957218.html
Sent from the Mono - OSX mailing list archive at Nabble.com.