MonoDevelop Mac Preview Builds

The past few weeks I've been working on improving the MonoDevelop experience on the Mac, making it integrate better with the Mac experience. Along with ASP.NET MVC support and other soon-to be-announced excitement, I think this makes MonoDevelop much more interesting for Mac users.

MonoDevelop with Mac main menu support

Among other things, I have:

  • Abstracted out the main menu and reimplemented it as a native Mac global menu.
  • Added handlers for Mac events, such as Quit, Dock Click, Open Files, etc.
  • Added Mac-specific command accelerators.
  • Made it possible to capture the Mac Command and Option keyboard modifiers for accelerators.
  • Made accelerators display everywhere using Mac-style glyphs.
  • Tweaked the text editor's caret and selection navigation to behave more like a Mac IDE, including Alt/Control word/subword splitting.

This has been made difficult by the native GTK+ Mac. Although the basics work very well, there are substantial problems with some of the more advanced things we do, such as key capturing for accelerators, and custom widgets. In the future we will be fixing issues upstream and shipping patched GTK+ builds with Mono, but for now I've been focussing on making everything work with the released Mono 2.4.

To do much of this, I had to build a large set of Carbon P/Invoke signatures and wrappers, and getting these right took some time. It seems to me that this could be the basis of a "Mac Bridge" in the style of the Vista Bridge. Having such managed wrappers would make it easier for developers to make their apps integrate more closely with the unique aspects of various platforms.

This work will be released in MonoDevelop 2.2. Right now it's not finished, and is very much an alpha. However, since it's already a substantial improvement for Mac users, I am making available a Mac preview build. This is a trunk build that has undergone no QA testing. I simply update it whenever I feel that trunk is usable and bugfixes or improvements have been made since the previous build. Use at your own risk. I have already listed a number of known issues.

Download it from the Mac Preview page on the MonoDevelop website.

If you do run into problems that aren't on the known issues list, please file bug reports. And, as ever, contributions are more than welcome.

Comments

This is already an awesome improvement over the previous Mac builds, thanks! I used these this morning to build the latest Tomboy release, and was very pleased with all the fixes.

The work you're doing is going to be extremely useful to all the other GTK# app developers looking to improve their Mac offerings.

I thought Carbon is not transitioning to the 64-bit world with Leopard. Shouldn't you be writing a Cocoa (or the lower-level C Foundation) P/Invoke bridge? I thought the story was that Adobe was once hoping to use 64-bit Carbon to bring Creative Studio apps into Leopard and 64-bit, but Apple decided to only implement Cocoa as the API going forward to 64-bit and now Adobe has to rewrite all of its apps in Cocoa. (I have a link to one of the many stories about Adobe's plight, but the commenting engine won't let me submit it.)

In other words, this might be a Mac Bridge to nowhere...

Not to be ungrateful, though, thanks for putting in this effort. I'll give the new build a try.

Gtk+ uses Carbon hence the use of Carbon.

The 32-bit limit for an IDE does not seem like it is going to break any of your editing sessions. Until you start editing 4-gig text files, 32-bit will be plenty of room for the task.

The main problem is, that the old "not 64bit capable" APIs will be removed in the future.

I don't see that happening anytime soon. Apple's third-party software ecosystem is already small enough.

We can cross that bridge when we come to it.

Not the whole Carbon will be removed. Some parts are available in 32/64bit (the new stuff), some parts are still 32bit (the "newer" old stuff) and some parts will be removed completly (the really old stuff from the OS9 system) and you have to use the new API.

You have to read to documentation carefully. If an API is marked as "32bit only" then it is not useful to use it in new projects. Mostly there is a new API only with another name and some more or less parameters.

For example the API for keyboard layouts:

The old 32bit-only API:

KeyboardLayoutRef key_layout;
const void *chr_data;
KLGetCurrentKeyboardLayout(&key_layout);
KLGetKeyboardLayoutProperty(key_layout, kKLuchrData, &chr_data);

and here is the new 32/64bit API:

TISInputSourceRef key_layout;
const void *chr_data;
key_layout = TISCopyCurrentKeyboardLayoutInputSource ();
CFDataRef currentKeyLayoutDataRef = (CFDataRef) TISGetInputSourceProperty (key_layout, kTISPropertyUnicodeKeyLayoutData);
chr_data = CFDataGetBytePtr (currentKeyLayoutDataRef);

Quite easy port, isn't it? Done in 5 minutes and the application is ready for the future... :P

Yes. Visual studio has not 64-bit version either

Hi,

Is there anything special required to target Moonlight binaries in MD?

David

(A) Thank you for Monodevelop/OSX and for the early port preview!
(B) Creating a moonlight sample project on MonoDevelop 2.1.0.0 and building it results in an error (respack failed: could not open assembly /Applications/MonoDevelop: no such file or directory (true - there is only /Applications/MonoDevelop.app)).

Is this a matter of my configuration that I can fix or a bug that would require a code-fix and recompile?

Why do you use GTK+ Mac and not Cocoa or Cocoa# ?

http://www.mono-project.com/CocoaSharp

I think a cocoa# port would be really great! But this is maybe a lot work.

Because a lot of the code in the internals (beyond the menus and windows) is tied to Gtk+.

Someone could certainly port it to Cocoa# but the result would not run on Linux and Windows.

Porting MonoDevelop to Cocoa# would involve forking all of the GUI and GUI-related code, which is probably at least 30% of MonoDevelop, so upwards of 200kloc. Obviously you'd also then have to duplicate all ongoing GUI code changes in MD. It would be a massive undertaking.

Using Mac GTK+ means we just have to fix bugs and tweak things to look/behave more natively. And even before everything's perfect, it's still usable.

Wow, thanks. This is a real step forward for Mono on OS X.

Does it come with the dark text-editor theme? If not, where can I get it?

Preferences->Text Editor->Highlighting, IIRC

I tried a new project via md.

Your .DMG is bad. After using any program to decompress the .BZ2, the .dmg errors saying "No mountable file system." Can you try to rebuild it and post it again?

On my 10.5 system, I download the file and it mounts automatically without any problems. I also haven't heard of this problem from anyone else. Maybe your download is bad?

I'm on 10.5.2, intel, and I tried first downloading and installing the framework from http://www.go-mono.com/mono-downloads/download.html . That seemed fine. I used universal

I then downloaded the monodevelop preview,
http://monodevelop.com/files/MacOSX/MonoDevelop-Preview-2009-07-06.dmg
When it downloaded, it became a bz2. It seemed to unpack fine, but then I got the error above, "no mountable filesystems."

Because of that, I went back and tried the intel (not as good for me since I have both systems), MonoFramework-2.4.2.3_3.macos10.novell.x86. Then after installing the framework, which again reported no errors, I retried Mono-Develop. It failed, same error.

I also tried the earlier monodevelop, MonoDevelop-Preview-2009-05-05.dmg, just to see if that helped. I got the same error.

That's very odd, as I haven't had any other reports of the dmg being corrupt; they seem to work for everyone else I've heard from.

Can you try the latest?

http://monodevelop.com/files/MacOSX/trunk-builds/MonoDevelop-MonoTouch-Preview-20090917-1.dmg

I have tried all the .dmg files including http://monodevelop.com/files/MacOSX/trunk-builds/MonoDevelop-Preview-20091111-2.dmg and it still comes out as corrupt.

Here is the output from hdiutil attach:
Checksumming Protective Master Boot Record (MBR : 0)…
Protective Master Boot Record (MBR :: verified CRC32 $346BEA18
Checksumming GPT Header (Primary GPT Header : 1)…
GPT Header (Primary GPT Header : 1): verified CRC32 $FE76FDDA
Checksumming GPT Partition Data (Primary GPT Table : 2)…
GPT Partition Data (Primary GPT Tabl: verified CRC32 $6A9E8326
Checksumming (Apple_Free : 3)…
(Apple_Free : 3): verified CRC32 $00000000
Checksumming disk image (Apple_HFS : 4)…
...
disk image (Apple_HFS : 4): checksum failed with error 1000.
...............................................................................
calculated CRC32 $910C0A3F, expected CRC32 $CE812B85
hdiutil: attach failed - image data corrupted

I'm getting that the dmg's are corrupt as well... http://twitpic.com/34k0u1

I got my setup working with Eclipse. I had confirmed that my Mono itself was working fine, as it runs from the command line. Note that I did make the softlink for pkg-config; that did not not change the dmg's non-opening.
sudo ln -s /Library/Frameworks/Mono.framework/Commands/pkg-config /usr/bin/pkg-config

I got Mono here;
http://www.go-mono.com/mono-downloads/download.html

I used Emonic, which is available from within Eclipse as a plugin;
http://www.eclipseplugincentral.com/Web_Links-index-req-viewlink-cid-1080.html

Nant command details are here; and we are using NAnt 0.86 Beta 1 Release December 8, 2007
http://nant.sourceforge.net/release/0.86-beta1/help/fundamentals/running-nant.html

This article gets C#/Eclipse to run on windows, but its hints for making the build.xml and reference to nant are pretty easy to change for mac;
http://www.ibm.com/developerworks/library/os-eclipse-migratenetvs/index.html

The only tough part was in Eclipse's GUI, I didn't get it at first. Do:
Run / External Tools...
the idea is to make two programs. Thus click on Programs.
Now, silently, the far left icon for "New" is available.
Click "New" and the rest of the directions are above.

For mac, our paths differ of course. Do
where nant
where mono
to check where they are.

The program for compilation needs nant and then it automagically uses g/mcs; I presume the csc tag in the xml sets it up due to Emonic.
The program to run needs to run mono.

When do you think that full VS2008 solution file compatibility will be available?

That depends what you mean by "full". We'll certainly never support some of the (especially non-.NET) project types VS supports. Support for loading/editing/saving core project types is quite mature, but if you do any MSBuild magic in the project files, that won't be supported until Mono's MSBuild implementation, xbuild, is completed and integrated to MD, probably MonoDevelop 2.4.

Hi guys,

Firstly, thanks for all of this great work - I am a .Net developer by trade but have a Mac at home, so this is superb for me.

One problem I have: MonoDevelop is running very slowly on my Mac, with the autocomplete taking for ever to appear and text not appearing in the code window fluidly when I type.

I have obviously not configured it correctly, given that I am the only one here, it seems, with this problem. I am running a modern MacBook Pro, so can't see that hardware grunt is an issue.

If anybody could help me out, I'd be very grateful, as I'd much rather support MonoDevelop than Eclipse.

Thanks,

Phil Whittington

Panic over - a restart of MonoDevelop seemed to work.

This is a great app - certainly all of the key features of Visual Studio I use are already here.

The Mono Framework is very mature now too, by the looks of it.

Phil Whittington

I'm glad you like it. Things have certainly come along recently, and we have some interesting goodies lined up for the coming months.

The performance issue is a weird one. It only happens on a few machines, and all users report that it goes away after restarting MD. I haven't been able to reproduce it, so it's very hard to debug.