[Mono-osx] MacOS bindings and MonoDevelop.
MacPgmr at fastermac.net
Tue May 12 19:43:31 EDT 2009
I'm taking a break from Mono work right now, but I have worked with
Cocoa#, Monobjc and a bit with NObjective. I'm exercising them by
writing the GUI in code, independent of Interface Builder. Here are
(1) The difference in performance between Cocoa# and Monobjc is
noticeable. On older hardware, Cocoa# is so slow to respond to events
that it acts like it's broken. I've dismissed Cocoa# as even a remote
possibility for production software.
(2) Eugeny's tests appear to indicate a performance advantage to
NObjective over Monobjc. While it's hard to imagine getting another
big bump compared to what you get by dumping Cocoa#, if there is a
real performance edge (and possibly lower resource requirements), we
would be remiss, if not downright irresponsible, not to investigate
NObjective as thoroughly as Monobjc. I want any performance edge I
can get, until somebody can convince me that my users won't
appreciate snappier response times.
(3) I'm currently waiting to see if Laurent can eliminate Monobjc's
dependency on System.Drawing. Referencing something as seemingly
innocuous as System.Drawing.SystemColors.ButtonFace in your code adds
a dependency on libgdiplus.dylib and all of its dependent native
libraries, as well as the X11 libraries, to your Monobjc app. Having
System.Drawing lurking there in Monobjc makes me kind of nervous.
NObjective does not have any System.Drawing dependency.
(4) Some things in Monobjc don't work yet. For example, I have not
been able to get some of the notification handlers like the
NSWindow.WindowWillClose or NSWindow.WindowShouldClose event handlers
to be called. I believe Laurent is aware of this. At least this
sounds like the problem I'm having, although not being an Objective-C
programmer I don't understand the workaround suggested:
(5) I started working with NObjective just before I decided that
maybe I would take a break from Mono for a while to see if a few
things work themselves out, so I don't have too much to report.
NObjective's assemblies are obviously a bit bigger in size than
Monobjc. For example, Monobjc.Cocoa.dll for 1.0 is about 1.5 MB,
whereas NObjective.Proxies.Tiger.dll is about 6.5 MB. Not sure what
accounts for the difference in size, although perhaps when
considering libmono.dylib's 14MB size it's not too bad.
(6) NObjective doesn't seem to have as many handy enums as Monobjc.
For example, I couldn't find the style mask constants that Monobjc
has as the NSWindowStyleMasks enum.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-osx