MONO

An ominous title, for yet another, but this time rather technical, guest post by EER.

Today I'll talk a bit about some crazy stuff I have been developing for work lately. As you may or may not know, I primarily work with .Net. Our government in the Netherlands is slowly moving to 'alternative' software platforms such as Linux or Macintosh.

Now Linux is not much of a problem, it is a developers' platform, and being a developer, I feel right at home using Debian or Ubuntu. But a macintosh is a whole different story. Luckily, I found the terminal after about two hours fiddling and everything is semi-normal if you just use the terminal ;)

Armed with a terminal and the latest version of the Mono framework I went about and tried to run my app. Of course, this failed horribly and I considered various options to get it all running. My first experiments with Windows Forms interfaces on the mac weren't very successful (to say the least). After inquiring on the mono-winforms mailing list, I was told to use the native Mac OS X driver by exporting the following variables from the terminal:

export MONO_MWF_USE_QUARTZ_BACKEND=1
export MONO_MWF_USE_CARBON_BACKEND=1

That looked a bit better than the X11 version, but still the stability was crap. So I moved on to check out the native Mac OS X interface programming framework "Cocoa". There are bindings available for Mono: cocoa#. These bindings are distributed with mono on mac by default.

So I tried to use them, which did not work as I came to expect from .Net when programming Windows Forms. So finally I'm coming to a point: Mac programming is different. How different you ask? I'll give you some hints to get started more easily:

• You must create the user interface with "Interface Builder" which comes with Mac OS X.
• Save the interface as a .NIB file, then use Application.LoadNib() in the cocoa framework to connect your code with the UI.
• In the Interface builder, you can create an object with predefined properties and actions. Your .Net class should be registered using attributes on your class.
• The message loop (Cocoa.Application.Run) does NOT return after when quitting. This is the last statement that is executed in your main method.

Code samples can be found in the Cocoa# source code, but I'll explain some of the attributes you can use:
  [Register("ControllerClass")] // You can use the Register attribute on a class to register it with the Object you have defined in the Interface Builder.
    [Connect] // Use the Connect attribute to link the public class variable to one of the outlets defined on the registered object in the Interface builder. These outlets can also be linked in the Interface Builder to various components in your NIB. For this to work, your object needs to be delegate for the component you want to access here.
    public Cocoa.Panel aboutPanel;
    [Export("show_about:")] // You can use the Export attribute to link class functions to the functions defined on the registered object. These functions will then execute managed code when they are called from the UI.
    public void show_about(Cocoa.Object sender)
    [Export("applicationWillTerminate:")] // The last one, still an Export, but this is the one you will need for cleanup code. As the Messageloop does not return, this is the event handler if the application is terminated by pressing Quit in the dock. For this to work, the registered object should be delegate for the application.
    public void ApplicationWillTerminate(Cocoa.Notification not)