My name is Michael Hutchinson and I'm a software engineer working for Xamarin on the MonoDevelop IDE and Mono for mobile platforms. Here you can find my journal, projects and photos.


How not to break Mono installations

It's a bad idea to mess with the packaged version of Mono on your Linux distro by installing another version of Mono on top of it or into another of your distro's standard prefixes such as /usr/local. Your distro's developers, testers and packagers have tested the packaged version of Mono to make sure that it works with the various applications that depend on it, such as MonoDevelop, Tomboy, F-Spot, Beagle and Banshee. In addition, you're likely to end up with unusual errors due to mismatched bits and pieces interacting in unpredictable ways.

If you need a more recent version in order to test new features and bugfixes, please keep a properly separated parallel Mono environment. By following these instructions you can ensure that you don't affect your stable Mono platform while experimenting with newer versions.

This applies to platform bindings such as GTK#, GtkSourceView# and GNOME# too!

GtkSourceView 2 in MonoDevelop

I recently added support for GtkSourceView 2 to MonoDevelop, and it can be enabled with the "--enable-gtksourceview2" configure switch. Unfortunately the Boo Binding and the Database Addin depend on GtkSourceView# directly, and aren't compatible with the API changes in 2.0. I may get round to fixing them later. However, I've already switched on GtkSourceView2 support in my MonoDevelop build repository. The main reason I did this, of course, was the wonderful dark grey colour scheme "oblivion" :-)

The GtkSourceView2# binding isn't officially released yet, and will probably get absorbed into the Gnome# platform bindings, but right now it seems to work fine.
Packages for openSUSE 10.3 are available from my MonoDevelop build repository.

Notable new features are:

  • Improved syntax highlighting
  • Support for colour schemes

Notable missing/removed features are:

  • Printing
  • Bookmarks (also used for debugger breakpoints, when the debugger worked)

There isn't a UI for changing colour schemes yet, but it can be done manually in the ~/.config/MonoDevelop/MonoDevelopProperties.xml file by setting/adding the property <Property key="GtkSourceViewStyleScheme" value="oblivion" /> within the property <Property key="MonoDevelop.TextEditor.Document.Document.DefaultDocumentAggregatorProperties">.

MonoDevelop trunk builds

Hot on the heels of Lluis's MonoDevelop 1.0 Beta 2 announcement, I'd like to announce the availability of frequent builds of MonoDevelop from SVN trunk, packaged for openSUSE 10.3. If you'd like to get the latest and greatest bug fixes and features but don't want to build MD yourself, head over to my openSUSE Build Service Sandbox. The packages will also come up in the openSUSE search for MonoDevelop packages.

Warning: these packages are not guaranteed to be stable, though I'll try to push only usable revisions. I may also enable and disable features at a whim, e.g. disabling the Boo binding and MonoDevelop.Database addin in order to enable GtkSourceView 2 support.

Update: the sandbox link currently requires that you're logged into the openSUSE Build Service, so here's a direct link to the repository.

Joined Novell, and moving to Boston

I apologise for not having updated my blog more often. Things have been quite hectic recently...

A month ago (as announced by Miguel de Icaza) I joined the fantastic Mono team at Novell, working on the MonoDevelop IDE. Since then I've been busy getting the ASP.NET Project features ready for MonoDevelop 1.0 Beta 1, which we finally released on Monday. It's essentially feature complete for 1.0, except for the "Web Deploy" feature that didn't quite make it into the beta but is currently in SVN trunk.

My "free" time has been taken up with preparing for my upcoming move to Boston, MA, USA this weekend. I'll soon be working with the cool people in the Novell offices in Cambridge! This move is a little daunting, as I've never been outside of Europe before, but I'm really excited about it.

International Talk Like Pirate Day

Fetch me spyglass! I just realised 'tis International Talk Like A Pirate Day and I ha'nae installed th' Drupal Pirate Filter on this incarnation o' me site.

Notes on GUADEC

First of all I'd like so say what a great experience GUADEC was. It was great to talk to cool people, see the amazing software people are writing, and hear talks from inspiring speakers. It really emphasised for me why having such a diverse yet coherent community has made GNOME the awesome ecosystem it is today.

I'm a little disappointed I could only attend the Core days, but I think they were enough for me. I'm currently away and it's not easy to write or post to my journal, but I've patched together some notes on the talks I attended.

Tuesday: Core I

OpenMoko: I can't wait to get one and put Mono on it. There will be loads of incredible applications.

LibGnomeDB: This looks like a good start to do bespoke data apps in C or C++, but it's not even close to the kind of databinding we need in GTK# to compete with SWF.

Ari Jaaksi's Keynote: An interesting perspective on F/OSS from Nokia's viewpoint. It's worth bearing in mind that support and training costs prevent commercial concerns from being as agile as hackers.

Telepathy and Tubes: Great stuff. This should be everywhere. Could F-Spot use it for photo sharing? Could Banshee-NG-DBus use tubes to replace DAAP?

Metadata Overview: Joe explained the current state of metadata on the Desktop and made a good case for aggregating separate metadata stores rather than using Tracker's approach of squeezing everything into a one-size-fits-all solution.

Havoc's and Bryan's Keynote: I fully agree that integration with online services is key to the continued success of GNOME, and could be a good way to expand our user base. But beware of getting people locked into proprietary services.

Wednesday: Core II

Keynote: Disappointed the speaker wasn't there, as I dashed to make it on time. However, Michael Meeks' replacement talk on using a simulated disc to calculate reproducible I/O times was pretty cool.

New Main Menu: Jim gave a nice account of the reasoning behind the cool new Main Menu. I like the way the 'tiles' are being used elsewhere; they should be part of the platform. One thing I'd like to see is a huge main menu instead of the desktop...

Lowfat: MacSlow demonstated his really cool user interface, but I see it as having a limited scope. Why limit ourselves to physical metaphors? My real desktop is often a mess. I would love to abolish the "desktop" metaphor completely. It's a horribly inefficient use of screen real-estate, so I certainly don't think it'll ever filter down to small mobile devices.

Alex Graveley's Keynote: Pyro Desktop is an awesome hack, and I'd love to see web developers welcomed to the desktop. However, I don't think desktop developers should move that far towards web-style inefficiency...

Lightning Talks: In particular I remember the Giver/Tomboy note sharing over Avahi. It's simple, yet I imagine it could be very useful. It would be nice to have this on every electronic device I own. I also saw Banter, which I'd love to be able to try myself (segfaults from unmanaged land have prevented me thus far). The short version of Michael Meeks' talk with Federico was fun.

GTK+ Status: Looks like there are some nice improvements to look forward to, but nothing earth-shattering.

GTK+ 3.0 Discussion: No progress at all. A small group of people argued over what we can't do. What I took away from this was 'there will be no GTK 3.0'. The only way to make it workable in my view is to write a separate canvas-based toolkit library that can be embedded in GTK and vice versa. Eventually some apps will be able to drop the GTK dependency. I suspect that an ABI-stable GTK 2.x will stay around for a very long time.

Thursday: Core III

Robert Love's Keynote: Nice presentation of the wonderful Summer of Code program, though little was news to me. Shame about the fire alarm.

Clutter: Cool. I need to play with the Mono bindings. Wish I had time to write a widget set on top of it, with a widget interface/theme separation. This would be a good start for GTK 3.0. Indeed, why not write a toolkit like Moonlight, in that managed code is only binding to unmanaged code at an intermediate level?

Stormy Peters' Keynote: Nice presentation, though we already know that developers are creators. Good luck getting this across to companies!

Tracker: The metadata store sounds like a cool idea, and once you start thinking in terms of triples it's extremely tempting to extend them to everything. I almost fell victim to a similar hubris a few years ago. But you can't know everything about everyone's data. It's just not possible. There will always be different ways of doing things, and the key is to aggregate them intelligently, not reinvent everyone's wheels.

Doc Searls' Keynote: VRM is a nice idea, but I'm not quite sure how it fits into GNOME... It was a good keynote though.

Federico's Surprise Closing Keynote: Inspiring, and great to hear about GNOME's roots. We really need to think about new kinds of apps and "desktops", as we pretty much have the best "conventional" desktop in the world. How can we go beyond this?


The best thing about GUADEC was meeting people: Gabriel, Patrick, Rodney, Toms, Aidan, Aaron, Jim, Joe, Fabian, and many others. Thanks for making it a fun place to be!

GUADEC has a great experience and made me think a lot about the future desktop and mobile devices, and how Mono fits in with them. My opinion on how proprietary online services affect the Free desktop, which is something I've been thinking about a lot for a few months, has now developed to the point at which I'm prepared to write publicly about it. I shall be posting a series of discussions and ideas over the next month or two.

Going to GUADEC 2007

I'm going to GUADEC 2007, because

  • I hack on a GNOME IDE, MonoDevelop
  • GNOME is cool, and there will be lots of cool people at GUADEC
  • Birmingham is under five hours away by train

If anyone would like to meet up to chat about MonoDevelop, Mono, GNOME, Drupal, or anything else at all, please drop me a line or post a comment, and I'll do my best to find you. I'm afraid that due to other commitments I'll only be around during the Core days.

Silicon Group: How to Lose Customers

I went to the Silicon Group computer shop on Dalry Road in Edinburgh today to buy a couple of 2GB high-speed CompactFlash cards. Their website, updated three days ago, advertised that it cost £15, which by current standards is an internet-level price. I've used them in the past, and they've always provided reasonable components at prices that are pretty low for a High Street shop. More recently I'd been tempted by the lower prices and vastly superior range offered by web retailers, but decided to save the postage and give Silicon a shot.

However, when I got to the shop they wanted to charge me double the price for inferior memory. Apparently the website and the PDF pricelist on it only apply to their Alloa store, despite not stating this and advertising both addresses with equal prominence. The Dalry Road store staff pointed at their own one-and-a-half months older pricelist, and quoted me an even higher "updated" price of £30. They were unapologetic: I should have phoned in, I could go to Alloa. I got the impression that they considered it to be my fault.

Come on, guys, you're running a computer shop! It should take minutes to post prices, or you could even do it "automatically" using a "computer program". Or if you don't want people to wonder why one store charges twice as much for memory as the other, just post a note to the effect that the prices on the website don't apply to your Dalry Store.

I guess I'll just have to order some high quality ultra-fast SanDisk Extreme III cards from the net for two thirds of the price that Silicon wanted. And it's unlikely that I'll visit them again.

Sakura Teppanyaki

Yesterday I went to the Sakura Teppanyaki (鉄板焼き) Restaurant in Durham with a group of friends, and it was by far the most interesting meal I have ever had. In a teppanyaki restaurant the chef prepares the food on a large, flat heated stainless steel surface in the middle of the diners' table, in an utterly fascinating performance. It started with a ceiling-high plume of fire, and our chef looked like he was having fun, deftly juggling eggs and cooking implements, and using them to play little tunes on the cooking surface!

The food was really good, served up as soon as it was cooked. I had the "house special" menu which contained a range of different foods; I particularly liked the salmon and the teriyaki chicken. All in all, it wasn't cheap — twice as expensive as the next most expensive meal I'd ever had — but well worth it for the whole experience.

Rethinking ASP.NET Project Models

I've been thinking again about the compilation and deployment models used in MonoDevelop for ASP.NET code, and it isn't easy to come up with a good solution. I've written a discussion of the various possibilities and how they mesh with MonoDevelop and the Visual Studio way of doing things.

In VS.NET 2003, the Web Application model necessarily used the 1.1 CodeBehind model. This enforces no constraints on project layout at all; all the compiler has to do is compile all C#/VB.NET files into a library in the bin folder, and deployment is similarly simple. In order for controls in the inheriting pages to be accessible from the CodeBehind class, they must be added as fields to the CodeBehind classes, which the IDE does when the visual designer is used. This is the model that MonoDevelop uses at the moment.

The initial release of Visual Studio 2005 replaced this with the Web Site model. All CodeBehind code is compiled into a library by the server when the relevant page is hit, and any additional code must be in the App_Code directory. The CodeBehind classes are partial classes, and the server's compiler generates another partial class containing all of the controls in the inheriting class, so that they can be accessed by the CodeBehind. Everything gets deployed; alternatively, the site can be edited in place. There is a program called aspnet_compiler.exe, which can be used to precompile all the code, and even the pages, and it can be invoked during the deployment process. The major strength of this model is the capability to perform in-place editing. It is also the only model supported by Visual Studio 2005 Express.

A later addition to Visual Studio 2005 was the Web Application model. This is very similar to the VS.NET 2003 model, except that it uses partial to make inheriting pages' controls accessible from CodeBehind. Since Mono's mcs compiler supports partial classes, MonoDevelop could use this model for websites targeting either the 1.1 or 2.0 runtimes. The downside of this is that it would make compatibility with VS.NET 2003 harder.

The real difficulty of designing the ASP.NET project model in MonoDevelop is in trying to support both the Web Site and Web Application models. In order to appeal to migrating developers, we really need to support both models, especially as Visual Studio will be supporting both models in the future. Do we try to merge them into one? Write a project model that's so flexible that it supports both paradigms, but is horribly confusing? The thing is, the two models are designed for fundamentally different purposes: a Web Site for quick-and-easy projects, or a Web Application for a controlled development cycle.

If I were to design a single project model with no regard for compatibility with Visual Studio projects, I'd have a strict file layout like the Web Site model, with all code in App_Code. The IDE compile phase would then compile all the code that would not be compiled by the Web Site model, allowing more control over compilation where necessary. All CodeBehind would use partial classes.

In summary, the big choice is between having separate Web Application and Web Site project types as Visual Studio does, or folding them into one composite model, or having an overwhelmingly configurable project type allowing all development models as options. The big concerns I have are are usability, and compatibility with Visual Studio, particularly VS.NET 2003/.NET 1.1 as it does not allow the use of partial classes.

I'm not sure how much VS.NET 2003 is used now, and developers can of course port their apps via Visual Studio 2005. I'm leaning towards having separate Web Application and Web Site project types, and only supporting ASP.NET 2.0.

I would welcome any insights and ideas that people can offer.


Subscribe to Journal