[Mono-osx] 3 cross-platform questions

[Mac Programmer]

Andreas,

Many thanks. That pointed me in the right direction.

Apparently Cocoa# apps are normally started like this (using Prism  
syntax):

     Application.Init();
     Application.LoadNib('Main.nib');
     Application.Run();

By looking at what LoadNib is doing, I found that I can eliminate the  
need for a .nib by starting it like this:

     Application.Init();
     (new MainForm 
(Application.SharedApplication.Zone)).InitializeComponent();
     Application.Run();

where MainForm is my class that has a method named  
InitializeComponent that creates the window and controls, etc.

Dependence on a .nib file troubles me. I don't like that it's not  
human readable and not easy to manipulate with other software.  
nibtool is provided, but this looks like something they created to  
work around some of the limitations of using an off-beat proprietary  
format. It appears as though gnustep's Gorm can read and write .nib  
files, but I haven't been able to get Gorm compiled yet to test that.

One of the more interesting aspects of Prism is that it's apparently  
able to read .nib files in order to auto-generate the partial design  
class each time you modify the .nib in IB. That strikes me as a  
fairly impressive feat.

I appreciate that a .nib contains serialized objects and is not a  
representation of the UI the way, say, a Delphi .dfm file is, but it  
seems kind of archaic. I wonder if it's really just a throw-back to  
some ancient time when computers were much slower than today.

I like having something other than just the visual part to look at.  
Code is fine, as is a .dfm file or something like that. One of  
my .dfm files is 6,000 single-spaced lines, but I can open it with a  
text editor and read it like a novel.

Thanks again.

-Phil


On Feb 25, 2009, at 4:36 PM, Andreas Färber wrote:

>
> Am 25.02.2009 um 01:58 schrieb Mac Programmer:
>
>> (2) Is there a way to create a Cocoa app in Mono without using
>> a .nib?
>
> Yes, there is. If your application calls the default  
> NSApplicationMain(argc, argv), then it tries to load a .nib, as  
> documented by Apple. If instead you call a subset of the Objective- 
> C methods involved directly, you don't need one. E.g.:
>
> int main(int argc, char* argv[]) {
>     [YourApplication sharedApplication]; // create instance, assign  
> to NSApp
>     [NSApp run];
>     return 0;
>     // vs. return NSApplicationMain(argc, (const char**)argv);
> }
>
> The advantage is that it makes incremental localization easier for  
> me, I can load sensibly named strings from .strings files and adapt  
> sizes instead of having to localize a whole .nib file. The  
> disadvantages are setting up some of the Cocoa controls is more  
> complicated than clicking them together in Interface Builder, with  
> little documentation available since uncommon, and deserializing  
> a .nib archive to memory may be more performant than doing  
> sequential initializations from code.
>
> An MVC design and the use of a graphical interface designer tool  
> are orthogonal to each other imo.
>
> Andreas
>