[Mono-osx] Creating plug-in bundles with MonoMac?
lists at philjordan.eu
Mon Apr 4 06:23:56 EDT 2011
Sorry if this has been asked before - I couldn't find anything
relevant in the archives.
I'm pretty new to Mono in general and MonoMac in particular, so
attempting this may well be ridiculous, but: is it possible to create
Cocoa application plugins using MonoMac? In particular, I'm thinking
of a .prefPane for System Preferences. So instead of building a .app
bundle, this would need to be a "loadable bundle" binary, exporting a
Generating NSPreferencePane bindings for Mono seems straightforward
enough, at least - I've done a preliminary run of parse.exe and
bmac.exe on it, and that went well enough after a few tweaks - haven't
actually tried running it yet though:
My understanding of MonoMac is that it registers the NSObject-derived
classes with the Objective-C runtime at, er, runtime. I know MonoTouch
uses AOT compilation of some sort, but it's not clear to me if this is
supported for MonoMac or if this generates static Objective-C runtime
info. So I assume that in the worst case, we would need to subclass
NSPreferencePane in Objective-C, start up a Mono environment upon
initialisation as detailed here
http://www.mono-project.com/Embedding_Mono and let it register its
Objective-C classes with the runtime, then proxy all messages to the
preference pane object implemented in C#?
I'm worried that this is going to cause all sorts of problems down the
road, such as receiving messages on a thread created by the
application not under my control causing Mono to get confused, and the
app expecting to handle Unix process signals that Mono hijacks. I'm
thinking of NSProcessInfo's "sudden termination" in particular, but
there may be others. Plus there's the possibility of other plugins
using Mono - will the two domains interfere?
So basically, is this feasible or is it a Really Bad Idea/more trouble
than it's worth?
More information about the Mono-osx