Stetic Lluis completed the work in Stetic, the Gtk# GUI designer, to support menu and toolbar editing. His work is based around Gtk+ UIAction/Action/ActionGroup, which takes advantage of the new features in modern Gtk+'s.

MonoDevelop hosting the updated Stetic GUI designer.

Read his full blog entry for further screenshots and explanations. The code is available on trunk.

MonoDevelop and C# 2.0: on the same blog entry Lluis talks about the integration of SharpDevelop 2.0's NRefactor code. This means that MonoDevelop will now do proper completion and parsing of C# 2.0 projects (Generics, anonymous methods, partial clases and so on).

Zac Bowling: has two interesting posts this week: his progress on Mozilla embedding. His post describes his work to give us finer control over embedding Mozilla in our applications (in particular to implement Windows.Forms's WebControl).

He also has a very nice post about uses of Mono beyond running your application on Linux and tips for .NET developers.

Google announced Picasa running on Linux, I agree with Robert Love's opinion that using and improving Wine was the right thing to do for Google. Wine and Picasa stability and performance are very impressive.

Independently of the open source debate surrouding Java, I enjoyed very much this blog entry from Sun's CEO. In particular:

I'm still amazed when I hear folks wondering how Sun monetizes Java. So at the risk of repetition, I'd like to share a few thoughts.

...

Then there was the civil war era in the US, when locomotive companies all had their own railroad widths and shapes - designed only to work with their rail cars and steam engines. How'd they fare? They failed, standards emerged that unified railways and rail lines, and that era created massive wealth, connecting economies within economies. Standards grew markets and value.

The Google Summer of Code has started, and we have announced the list of projects that will be mentored in the Mono group here.

This will be another exciting summer.

Disclaimer: I do not know how people are using continuations to build web applications, but on the ongoing debate about continuations and the web, Ian Griffith's has a small tutorial and makes the following observation which sounds sensibe:

But continuations seem to offer a solution. Whenever we get to the point in the code where we need to generate a page and feed it back to the user, we could create a continuation, store it somewhere, and then return control to the web server. When the next request comes in, a framework could retrieve that continuation, and execute it, allowing us to continue from where we left off.

You could probably cruft up a working example of this style of coding in a web app by writing an iterator function in C# which did a yield return each time it wanted to show a page to the user and wait for the results. Languages with comprehensive support for continuations could offer a more elegant example of the same idea.

However, I think this is a bad idea. Although the relationship between the code and the user navigation path is apparently simple, it hides subtle but significant details. This makes the same mistake as we did in the 1990s with distributed object models. We'd like to believe we're hiding a lot of implementation details behind a simple abstraction. In practice we're hiding important features behind an inappropriate abstraction. Our industry has more or less learned the lesson that procedure calls are an unworkably naive abstraction for request/response messaging over a network. I suspect that it's equally naive to attempt to manage the complexities of user/web server interactions with simple sequential code.

(Emphasis added).

There is some discussion about whether the JVM CLR should add support for continuations. And Don Box doubts that Web Applications are the killer app for continuations.

We abused iterators last year to implement our HTTP application pipeline, but am not sure this is something that can be easily generalized and is certainly not easy to explain.

In the meantime, Tomi Valkeinen has prototyped a continuations framework for Mono.

Update: Even if there is a good design for a web framework that uses continuations at its core, doesn't this require the state to be preserved in the server in some form?

Mono competes with Java, and as Chris said a few weeks, am sure I have some agenda here. But I believe in open source and free software. Ultimately, a free java is just what the doctor ordered.

Like every other pundit on the magazines, this is my followup into the speculative Java debate.

Am reading the recent quotes from a Red Hat executive on the Register (so I guess we have to take these comments with a grain of salt, as the Register is highly selective about what it quotes and how it quotes it), but they ring true.

Regarding the new binary license and Sun's announcement this week, he said:

"They try to do the minimal amount they can get away with,"

Am sure that Sun has its own reasons for doing a calculated release of Java, but they have a good track record of following up on their promises: OpenOffice and OpenSolaris (and I guess they are also GPLing their CPUs, not sure).

The OpenOffice strategy was in the hands of Marco Boerries who has now departed Sun. And in the case of OpenOffice the value was in bringing down the leader in the space (Office); While in the Java case its a matter of opening up the leader (Java) and potentially loosing some leverage in the industry.

Now, when it comes to the one laptop per child project and Java, its interesting to note what Chris said recently:

Everyone has agendas. We ran into quite a few at this point in development. People who wanted us to use Java for Java’s sake, people who wanted to see their particular software on the laptop, people who wanted to control what kids would see, and what educational content they would be exposed to - everything.

Red Hat is clearly now a company with a lot invested in Java and much to lose from Sun's control over such a core component of the OS. I have no way of confirming if the Register correctly paraphrased their CTO, but the reasons given had nothing to do with JBoss and everything to do with some research-grade projects: OLPC and Real Time Systems?

In any case, it boggles the mind that people would like to run everything on Java on those poor OLPC machines. They have as much power as my cell phone (and Java has brought down and rebooted my phone more times than I care to remember; Granted I spend too much time in Google Talk and Google Maps).

Now, on the other hand, everyone clamoring for Sun to open source Java seems to be tacitly admitting that free software can not compete in out-engineering a proprietary company if the proprietary company gives their goods for free, a point that I have made previously ("Fork in the Open Source Java world" and "Open Source Java, Part 2"). Tom Tromey did have an interesting follow up to my negative outlook (finding the post is an exercise for the reader).

He certainly does not agree with me, and its very possible that my passion for Mono might influence my motivations, but in the end an open source Java is good for everyone.

Beyond all the debate surrounding Sun's actions there is an interesting debate that we should look at: can open source effectively competing with proprietary software if the goods are given away for free?

I believe we have overestimated the need and importance that people put on open source software over the need for free software (free as in price in this context, gratis). This is one of my points in the previous blog entries.

Points to ponder: effect of free VisualStudio Express over SharpDevelop. The new license that allows binary distributions of Java among Linux users. Free Flash player over the three hundred incomplete efforts to reimplement it for free.

Discuss among yourselves.

Update: Some confused readers did not make the connection and are missing my point, so I quote a bit from the earlier article

Unlike Mono, open source Java faces a big problem: there are a number of free commercial Java runtimes available for every operating system that matters. The group of people who would have contributed to a free java to scratch an itch are gone. From those who remain another large chunk will switch in a heartbeat to a commercial implementation the moment they run into missing features, scalability issues, the lack of a moving GC or a hard to debug problem.

So you must rely purely on free software advocates or people employed to clone Sun's Java for a strategic purpose.

As I mentioned in someone's comments section, broaldy speaking there are two large groups of contributors to open source software: free software kind, the activists, the idealists and the pragmatists, scratch-their-own-itch kind.

Open Source Java moves slower because it lacks the second group of contributors. That group is happily using Sun's Java. Mono on the other hand has been able able to benefit from contributions of the second kind. The day Microsoft releases .NET for Linux/Unix is the day that Mono looses a big chunk of the second kind of contributors.

An interview with Rick Brewster, one of the authors of Paint.NET, available here.

Some quotes:

I nominated myself to the project manager position and the four of us (Brandon Ortiz, Chris Trevino, Luke Walker, and myself) kicked out a v1.0 product in about 15 weeks. We didn't start with the source code to Paint, but instead built Paint.NET from scratch -- I was quite impressed with how easy it was to build an application in C# and to keep it organized.

...

The primary goal of Paint.NET is ease of use. One rule of ease of use is recognizing that "people don't." They don't follow or even read directions (I certainly don't), they don't read dialog boxes (I hate dialog boxes), they don't backup their files, etc. And many people aren't interested in figuring out all sorts of complex or technical things. They just want it to work.

...

I don't believe that we should be aiming to replace Photoshop or The GIMP.

The rest of the interview is great, I recommend reading it.

Paolo just got back from vacationing in Egypt. Rodrigo loved it and tried to get me to go ever since he got back. Now Billmon is going too to cover the WEF and then doing some tourism.

Its been on my TODO list for ages.

Ideally, I should find myself an open source conference in Egypt as open-source based tourism is way better than just showing up at the airport and checking into your hotel.

In the last few weeks a large number of bugs have been fixed in our Windows.Forms implementation which finally has allowed us to get larger applications running with Mono.

As time goes by we are able to run more complicated applications with Mono.

In October I imported a version of Paint.Net, a paint application built with .NET into our repository. I made some changes to it to get it working on Linux, this is a screenshot as of this afternoon:

Paint.NET running on Linux

Paint.NET has been a fantastic test case, it is made up of about 70,000 lines of C# code. Update: The port runs in Mono, without any external dependencies (no Wine for instance).

Compiling Paint.NET on Mono: the first steps

To get the code building on Linux, I had to remove all the references to a third party library that was used by the Paint.NET back in October (DotNetWidgets). This is the last release of Paint.NET that targeted .NET 1.x; Newer versions of Paint.NET have replaced DotNetWidgets for the Strip controls in Windows.Forms.

The port is not as clean as I would like to, as I switched strategies in the middle of the port, let me explain.

First I used prj2make to turn the Visual Studio solution into a Makefile; Then I had to rename some of the files, as the actual filenames were spelled differently (filename casing) than the files distributed. This was easy.

A rather large and obnoxious task was replacing all the calls to DotNetWidgets (which provided Paint.NET with a spiced up UI experience) with the more simple widgets that ship as part of the standard API. This was done by removing the reference to the library and then changing the code to use the simpler widgets in a loop.

And this was my first mistake in the port. Instead of planning the port, I kind of brute forced the port on my spare time. About one third of the way in manually replacing the code in my favorite editor, I realized that I should just have implemented the DotNetWidgets interface and be done with it. The result was a 129 line source file that in one hour gave me everything I needed to get Paint.NET building without this dependency.

Exercise for the reader: describe the morale of the story.

Making it Run

This Paint application despite its young age is quite sophisticated and calls into a number of Win32 libraries to use features not exposed directly by the .NET libraries. For example, it determines the number of CPUs to adjust its thread pool, it uses low-level heap routines from the OS and other things like that.

Luckily all this OS-specific code is neatly split into the SystemLayer directory of Paint.Net and wrapped in a handful of classes.

Since most of these routines are very simple to provide in Unix I initially decided that it would be a good idea to implement these functions in a way that other future Windows.Forms applications would benefit, so I started implementing a number of routines that are now part of our "supporw" library.

Also, supportw is useful in showing how we can map unmanaged calls back into managed calls, so it was a useful example to have around for anyone which might need to "bounce" unmanaged calls into the managed world.

At this point in November, Paint.NET started running into missing functionality in Mono's System.Drawing and Mono's Windows.Forms; I would take a break of a few months before coming back to it a couple of weeks ago.

System.Drawing

One of the early road blocks that I ran into with Paint.NET was the incomplete support for Regions in our System.Drawing implementation. We supported rectangular regions, but not the GraphicsPath-based regions.

Implementing this was not an easy task. Around the same time we started working with a third party control vendor that uses System.Drawing extensively for his commercial product and we also ran into ZedGraph which is a popular library for generating plots which was running into some gradient issues with our implementation.

Sebastien was kind enough to take on the challenge of implementing these hard tasks.

ZedGraph in Mono, April 2006;
The original.

Sebastien blogged extensively about his work on GDI+, some screenshots:

• Colorful regions
• GDI+ Scans
• One Last Time

Blogging about this attracted Bill Holmes, which helped refine the finer points of the gradient brushes.

With GraphicsPath-based Regions implemented, gradients in place it is now possible to get most of the basic operations in Paint.NET going without a crash.

We are still missing support for "GraphicsPath.WidenPath" (used by Paint.NET to paint ellipses and rectangles, but really, who uses that these days? Aren't bezier paths all people need?).

Another missing feature are PathGradientBrushes. We do not believe that this can be implemented with Cairo, but we would love to be proved wrong. Cairo is the underlying engine that we use to implement GDI+.

Some of the us secretly wish that the Xara Xtreme library was already open sourced (they are planning on releasing it) but to use it, we would need it to be licensed under the LGPL or the MPL license.

System.Windows.Forms

Once the graphics issues were sorted out, Paint.NET turned out to be a QA engineer dream come true. After a while, we got to the point where we can actually draw with the program and we have fixed the most critical performance problems (initially it was not even possible to draw, due to a trigger-happy redraw routine).

Midways through the port, I changed direction. Instead of continuing to work on supporting the emulation of unmanaged APIs by emulation or by bouncing the API to managed code, I started to do a more regular "port". So I started to replace calls to SystemLayer with proper Unix calls or other Mono libraries. This has proved to be much simpler.

We might still implement a few emulation routines for some P/Invokes, depending on the popularity of the technique, but in general we will advocate that folks use OS-specific calls depending on their needs.

Paint.NET has exposed a lot of bugs in our Windows.Forms implementation (current bug list).

Sadly, in addition to the bugs reported, we need to fix also the minor details, and the cosmetic aspects of Windows.Forms before we can ship it.

At Novell, Jackson, Peter and Mike are now being joined by Atsushi, Gonzalo and Chris (who were up to this point working on ASP.NET 2.0) to assist in fixing bugs in Windows.Forms.

And of course lots of people in the community are helping out, specially Alexander Olk, Jordi Mas and Jonathan Chambers.

QA

Carlos is now working in collecting applications from the CodeProject and SourceForge and repeat the process that I described above for Paint.NET: we will be gathering applications as test cases and Carlos will be routinely testing them for potential regressions.

In addition, although we had a NUnit test case for Windows.Forms we were not really using it, so many failures went unnoticed for a while. So our immediate next step is to make sure that our NUnit tests pass on Unix (Atsushi just recently fixed them on Windows, as we had some incorrect tests or tests that depended on a specific release of the framework).

Atsushi has a great call for contributors that includes some background information on those which migh be interesting in helping:

So I have started to look around existing bug list and work on it. At first I thought that it is highly difficult task: to extract simple reproducible code from problematic sources, and of course, to fix bugs. Turned out that it is not that difficult. Actually, it is very easy to find MWF bugs. If you run your MWF program, it will immediately show you some problems. What I don't want you to do at this stage is just to report it as is. We kinda know that your code does not work on Mono. It's almost not a bug report. Please try to create good bug report. Here I want to share my ideas on how you can try creating good MWF bug reports and bugfixes.

Followed by some easy-to-follow steps on how to squash the bugs.

Other Mono Events

There are a number of exciting new developments in the Mono Universe that I hope to write about next week in more detail (news on our compacting GC, a new IR representation for Mono, a few touch-ups for our inliner).

The summer of code has some great proposals, and hopefully next week we will have the definite list of projects that we will be mentoring, but the one am most excited about is a VB.NET compiler (VB.NET 8, with Generics and all that) written in VB.NET.

Someone has adapted Colbert Report's "The Word" format to Bill O'Reilly's own "Talking Points", the result are pure gold.

hilarity link.

Thomas Friedman, "Six Months" remixed: Hilarious.

I liked this bit from the Ars Technica News coverage on Sun's rumored license plans for Java:

Sun's decision to make the license less restrictive is probably a response to the rapidly growing popularity of Mono, an open source implementation of Microsoft's .NET development platform. A variety of unique and compelling Linux desktop applications built with Mono have helped to popularize the use of .NET technology on Linux. The .NET runtime environment, known as the Common Language Infrastructure, is an official ISO standard, whereas Java is largely controlled by Sun through its own standards body, the Java Community Process. Java popularity is also threatened by the recent hype surrounding dynamic language web application development frameworks like Ruby on Rails and Django. Developers have found that web applications built with Ruby on Rails require less time and resources to develop and, in some cases, provide better performance than comparable web applications built with Java technologies like Spring and Hibernate.

This summer I will be participating in a series of lectures at Bertrand Meyer's LASER Summer School on Software Engineering in the Elba Island.

I will be talking about open source development.