In the first post of this blog series, we’ve taken a look at the new Add Reference pane for Mono that will be coming to a future prism release. Today, i want to talk about a feature that, technically, already ships in the current 3.0.15 release, but simply is not exposed via a nicely wrapped up template, yet.

When i was at PDC, i had the chance to catch up with Geoff Norton, who is the driving force behind the Mac OS X support in Mono. We talked a bit about the future of Cocoa# and Geoff suggested i should have a look at a third party library called Monobjc, which tries to solve the same problem as Cocoa# – making the Objective-C classes that form the basic of Mac OS X’s APIs available to managed code – but is at a much more complete state and provides better performance.

I liked a lot what i saw when i first looked at Monobjc in early November. From a user (read: developer) perspective, the library works very similar to Cocoa#, seems to be more stable and exposes a lot more functionality. The main differences for developers using Monobjc is that it maintains the original class names from Objective-C (Cocoa# dropped the NS prefixes, which i always thought was a mistake and caused a lot of confusion, not to mention duplicate class names that forced you to use System. or Cocoa. namespace prefixes all the time), and that it uses slightly different attributes to define the mapping between managed and unmanaged code.

So i set out to adjust the IDE support for Cocoa# development we have in Prism, to provide similar functionality for Monobjc. Basically, the development process will be the same as outlined in our wiki article on Cocoa#, but:

• A new Custom Tool (MonobjcNibGenerator) is provided to generate code from the elements in your NIB file to match what Monobjc expects. As explained above, this mainly constitutes of using different class names and different attributes; NSObject instead of Cocoa.Object, etc.
  
• Secondly, our MacPack MSBuild extension was updated to provide a new Monobjc option, because Monobjc expects the application bundles to be packed up slightly differently.

All of this is present in the current Prism release, if you know how to use it. What’s missing is a nice template that wraps everything up and gets you going with one click, as our current Cocoa# templates do. I would have loved to include that, but by the time the above features were going into SVN, we were less than a handful of days from RTM, so i could not really justify adding a new official feature and get it thru QA ;).

So what’s missing – and coming with the next feature release of Prism – is this:

a nice template that brings it all together and makes using Monobjc in Prism as easy as using Cocoa# is now!

I’ve been using Monobjc myself over the last few weeks, building a Mac OS X user interface for our upcoming DAServer6 (which will be part of Data Abstract later in 2009), and so far i must say i’m very happy with what i’m seeing. Cocoa# has numerous known bugs where applications would just crash if you pressed the wrong key or button, and severe performance problems when lots of round trips between managed and unmanaged code (such as when populating an NSTableView) happened. With Monobjc, i have seen no such problems; it runs stable and speedily, and the running application is literally indistinguishable from a “native” app.

I would certainly recommend giving Monobjc a try if you are doing Mac development with Prism.

With the first release Delphi Prism now out the door and in the hands of the first users, lots of people a starting to chat, blog and write about Prism in public, and it’s great to see all the excitement and the usually positive feedback. It seems that a lot of people who never gave Oxygene a second thought are looking at Prism now, and liking what they are seeing.

So with everyone else and their uncle starting to cover “Prism 1.0″, i thought it might be n ice to start a new blog series that will take a closer look at the labs to see what’s brewing in terms of new features that will come in future updates of prism, instead.

First in line is a feature that’s hot of the presses (i’m seeing it fully functional myself for the first time, today) that has been very close to my heart ever since i requested it <g>: a special Add References Pane for Mono.

This is just one more in many current (and future) features to make developing for Mono from inside Visual Studio easier. What happens is that if Prism detects that you’re working on a Mono project (my looking at the Framework Folder you have selected), it will expand the standard Add References dialog and show an extra page that gives you direct access to all the Mono dlls – from the standard system dlls to Mono-specific stuff such as Cocoa#, GTk#, Boo or the Mono.* dlls that extend the FCL.

Just a single click, and your Mono dlls are added to what we call the “shopping cart” area at the bottom (another Prism unique feature that makes adding multiple referneces in all project types much easier), ready to be added to your project: