Gtk+ 3.0, take 2

Emmanuele Bassi has summarized a discussion that happened on IRC after my Gtk+ 3.0 post.

His blog entry starts by saying that we should not use blogs to discuss and then goes on to discuss. I agree with the sentiment, but IRC is not a good place to do the meeting either as we do not even have IRC logs for whatever channel they were on discussing.

It is about the ISVs

Emmanuele seems to think that this is a marketing problem. It is not.

This is about the effect that the current Gtk+ 3.0 plan has on ISVs.

KDE has almost no ISVs, Qt does.

GNOME has almost no ISVs, Gtk+ does.

Most likely because anything beyond the core toolkit is too unstable in both cases, and because things are too quickly flagged as deprecated with no roadmap in place.

The Qt situation is much better, as it is commercially designed, and they have existing customers that are paying them money to solve problems for them, not introduce new ones.

Qt is also designed to be bundled with your application, and you can make your proprietary application not break if the user upgrades his Qt. This is not the modus operandi for Gtk+.

Having an "abandoned Gtk 2.x" and a "maintained, but API and ABI incompatible 3.x" which will not be available everywhere at the same time is a major turn off for ISVs.

Creating an ISV ecosystem is incredibly hard, and somehow the new generation of Gtk+ developers is now "OK" to throw away years of work of those that had to work with fewer resources than Gnome has today, fewer developers, a smaller community, slower computers, bigger challenges and yet, managed to keep Gtk+ 2.0 API compatible.

Perhaps it is not a matter of being "OK", but the new crop of Gtk+ developers does just not appreciate just how much value ISVs are for Gtk+, Gnome and the Linux desktop in the first place. They did not have to fight to get those guys on board on the first place.

The premises and the conclusions of Imendio's paper would not hold if you were to consider application developers in the mix. But in particular, it seems that the mindset is dangerously close to the rationalization used recently by a KDE spokesperson and lampooned by the Linux Hater Blog.

What bothered me last night

What bothered me last night after I blogged was the realization that most of the Imendio developers have switched to OSX as their main desktop operating system (At least rhult, hallski and kris).

These are great developers, but for their day-to-day activities, they have given up on the Linux/Gnome desktop. Their concern is no longer to attract ISVs, as long as the source compiles with some changes, they will be OK.

There are certainly some developers at Imendio that still use Linux, and I am sure they have a "Linux partition" to test things out. But when it comes to ensuring the viability of the Linux desktop ecosystem, I do not feel comfortable about wiping out the ISV ecosystem that we have.

Discussion

Emmanuele says:

for instance, I would have loved to have Miguel at the gtk+ team meeting of Tuesday at GUADEC: it would have been a great discussion, I’m sure of it, and we might have had a different state of the union talk.

I mentioned this problem in my previous blog entry. Even if I had made it to Istanbul on Tuesday, I am merely one of the voices concerned about API stability. "Tuesday Meeting at Guadec" is hardly inclusive:

There was no Adobe.

There was no VMware.

There was no Medsphere.

There were no Eclipse folks (who have complained previously about the ABI/API issues).

There was no Gnumeric.

And these are the ones I can think of the top of my head.

Senior voices from our own community were missing, like Morten Welinder who has expressed his opinion in a shorter post:

The best thing about tabs that I can think of is that it will keep certain people from doing more harmful things like changing the gtk+ api for no good reason.

I do not know who attended the Gtk+ planning on Tuesday, but it was not inclusive, and I suspect it was heavily tilted towards the Nokia-ecosystem.

From a Nokia standpoint, I understand the desire of dropping older code, get a smaller version of Gtk+ out there, and be able to get a very flashy system at all costs. The iPhone and OSX are strong UIs, and I can understand the desire to compete, but lets not throw the baby with the bathwater.

Decisions about the future of Gtk+ can not be done without all the stakeholders, and specially without those that have worked for years in keeping the API stability under duress and have built applications on top of it.

Features

Emmanuele says:

Yes, 3.0.0 might not have features. is this bad marketing? probably. so we need to fix this. a way1 to do this would be keeping the 3.0.0 in alpha state, call it 2.99.02 and add features to that until we get to a 3.0.0 that developers will want to migrate to, like the new scenegraph API or the new style API. let’s break with 2.x in style

As I said previously, I would endorse such a plan if it is shown that fundamental new features could not be implemented in an API/ABI compatible way. Nobody has yet refuted my assessment of the various areas that would not break compatibility, and that covers most of the new features.

Although I am not the only stake holder, nor the only ISV, nor the only developer.

Communication

Emmanuele says:

communication: there’s a certain lack of communication between the gtk+ team and the users of the library. in my opinion, it’s due to the small number of active developers and to the fact that ISVs don’t really get involved into shaping the platform they are using. they have the source code, and sometimes it’s easier to fix in-house than to communicate and go through the proper process — and this is a structural problem that is caused by the small number of people involved in the said process as well. the gtk+ team needs to open up more, and at the same time the ISVs need to get more involved. sometimes it feels to me that the team is waiting for features, direction and help in the development, while the users of the library are waiting for the team to come up with the perfect plan to fix all the bugs and warts while retaining the whole API and ABI.

I agree with Emmanuele.

We setup the GNOME Foundation for things like this; Lets use the GNOME Foundation organizational powers to reach out to ISVs; to organize a platform and Gtk+ summit as it is now clearly needed; Lets include all the stakeholders, not only the active developers.

Process

Emmanuele says:

process: this is connected to the first point - we have a lot of channels, and it might be daunting to actually follow them all; but we're also open in terms of discussion and revision. this is our strength. so please: if you want to discuss, join the IRC meetings on the #gtk-devel channel on Tuesday at 20:00 UTC or send an email to gtk-devel-list with your points. get involved. help shaping the future. don’t stand idly by, and wait for stuff to break to complain.

Casual discussion on IRC is OK, but that should not be the repository for decision making for such a fundamental component of GNOME and the Linux desktop.

Perhaps the discussion can start on IRC, but minutes, summaries and decisions should be posted to the Gtk+ developers and users mailing list and given enough time for all the stake holders to participate.

Additionally, you can not expect that your blog has now reached all the ISVs, not even the gtk-devel-list (which is presumably a mailing list for the developers of Gtk+ not for its users).

We need to have a mailing list discussion, and then we need to have an outreach program to get to all stakeholders, including the ISVs to formulate a plan.

Gtk+ 3.0

The Gtk+ 3.0 proposal being discussed currently sounds like a disaster for GNOME. The reasoning was first articulated in the histrionic Imendio Gtk+ 3.0 Vision presentation done at the Gtk+ Hackfest in Berlin. This is a meeting where application developers were underrepresented, and somehow we have accepted those proposals as the community consensus.

The proposal goes like this: Gtk+ 3.0 will hide all public fields in objects, provide accessors to these, remove APIs that have been flagged as deprecated and introduce no new features.

All the actual new features that some people want would come up in future versions. Which features will come is yet to be decided, because nobody knows when and what will be implemented.

There are lots of technical problems with the proposal, and from my discussions this week at GUADEC it does not seem that the Gtk+ developers have discussed the implications with the users of Gtk+.

There is a major strategic problem with the plan as well. The most important one is that there is no actual plan for which features will be added, and when these features will be added. There are no prototype implementations, and the idea of first developing the new features in a branch to actually study the code, the implementation and its potential APi breakage is not even on the agenda.

Basically, we are being told that we should trust that first breaking the API and hiding fields will suddenly enable a whole generation of new features to be implemented.

But it gets better. There are no guarantees that 3.x will not break the API if the feature in question turns out to require API breakage. Which means that we might actually end up in a situation where there will be multiple API breakages.

This by all means sounds like a bad plan.

Towards a Better Plan for Gtk+ 3.0

I am not against breaking the API for newer versions of Gtk+ if the benefits outweigh the downsides, and the execution presented is not bad. But "3.0 will help us clean up" is not a good enough reason.

We need:

• A Clear Roadmap: We need a clear roadmap of which features will be implemented and when they will be implemented. This is the first step to making decisions.
  

  A clear roadmap would also allow new developers to join the efforts and big companies like Red Hat and Novell to dedicate some full time resources to make some of these feature happen. As things stand today, we are basically being told to "wait-until-3.0-then-we-will-sort-it-out".

• Working Code: Before a feature for a future version of Gtk+ can be considered a reason to break the API, the technology must exist in the form of a patch/branch.
  This is not new, and should be of no surprise to anyone. This is how the Cairo integration into Gtk+ was done, how the layout changes are being implemented and how every other software product is ran.
• New API-breaking features must be publicly discussed with the community: Since this will affect every application developer (open source and proprietary) we should get the feedbacks of these communities.
  We could all get as excited as we want about a "gboolean bouncing_text" field in a GtkLabel, but that does not mean that we should break the API for the sake of it.
  Application developers were underrepresented at the Berlin hackfest, and even GUADEC is a microcosm of the ISVs that we had to reach. For instance, I did not see anyone from Adobe, VMware or Medsphere at the conference.
• Transitional 2.x Releases: For a long-enough period to get distributions to include the code, Gtk+ 2.x should include getter/setter macros to allow software developers to upgrade their source code to work with and without the public fields. To soft-land the switch to a hiding-field Gtk release (this is covered in the Imendio proposal).

This is by no means a comprehensive plan, it is only the beginning of a plan.

Lets please avoid inflicting in GNOME a KDE 4.0 (yes, I know its not the exact same scenario; and yes, I know those clock applets are cute).

Gtk+ Extensions

From looking at the original Imendio proposal. it seems that plenty of the things they want can be implemented without breaking the API:

• Animation: doable entirely without breaking the API. The animation/storyboard framework is an entirely new codebase, that would not touch anything in Gtk+. Some widgets might require smoother rendering on changes, but all can be done in an API-compatible framework. public API.
• Physics: same, add-on.
• Data-binding: same, add-on.
• Easier language bindings: same, add-on.
• Improved back-ends, more OS integration: Can not think of a major issue, but granted, I could be missing something, and Imendio has done the OSX port.

And my own favorite: killing all Gtk+ theme engines, and replacing it with a Qt-like CSS theme engine. This is not really an API break, as the only consumers of this code are the theme engines, and those we can safely kill and replace with CSS themes, no application code would break.

Maybe Havoc's proposal requires an API breaking change. And maybe this is worth breaking the API for. But breaking it for no gain, and no prototype to even understand the actual effects post 3.0 is wrong.

Update: For what its worth, I would lean towards breaking compatibility in 3.0 if it meant 3.0 would include the Havoc-like Scene system. That would make it worthier of a change.

Update: As usual, the Linux Hater Blog has some great commentary. Some of his feedback on KDE 4.0 applies to our own decision making. Worth a read.

RIA BOF at GUADEC

Thanks to Behdad and the organizers at GUADEC, I will be having a BOF/discussion session tomorrow at 4:30pm to discuss a new class of applications built on Silverlight or Flash and how they relate to the future of the Linux Desktop.

Some of the ideas are clearly derived from Alex and Chris thinking about the desktop; it is heavily influenced by our work on Moonlight; by the recent strides that Adobe has made on creating great looking applications on the web (Buzzword and Photoshop Express) and the future of Gnome.

Join me tomorrow for a discussion on how to launch an effort to create an open-source, RIA-based desktop applications.

I am very excited.

Guadec/Istanbul; Rich Desktop Applications.

Next week I will be attending the GNOME Developer Conference in Istanbul.

Looking forward to meet old friends and looking forward to discuss with people the future of rich applications.

BOF: Does anyone know how to apply for a last-minute BOF?

If there is some free presentation slot, I would like to hold an informal BOF to discuss these ideas.

Aaron and Banshee

Today I walked into Aaron's office unannounced and I just saw him glowing. Like a girl that has been kissed for the first time, like a donkey in the spring.

A voice in the background was narrating Banshee features, and I was wondering just what is that noise?

As I went around to his monitor to see what he was watching and listening to, I saw this Linux.com review on Banshee that included a screencast/podcast.

He was *so* excited that he was actually watching it in three computers at once.

I could not believe it.

Three computers at once. One, two and three. All playing the podcast. At the same time.

I was speechless.

From economic mastermind to flattered developer.

He said to me: "I have never seen a production of such caliber" as he listened to the background music in the above podcast.

I just stood there quietly. Unsuspectingly recovering the Twix office supply.

Moonlight 0.7 Installers

Yesterday I forgot to point to the actual page to install the Moonlight plugins.

You can download the latest plugin from here. Just like the last release, these plugins are compiled without ffmpeg support.

The source code is available here.

You can track the progress and try out a few applications yourself from our Moonlight Status page.

Moonlight 0.7 is now Available

A new release of Moonlight is now available. The team has been working very hard on improving the performance of Moonlight as well as improving our compatibility with Microsoft's Silverlight.

Get your copy here. Source code is moon-0.7.tar.bz2.

This release will also work with both Firefox 2.0 and Firefox 3.0. We have also switched our installation system to use signed XPIs, but we will also require a browser restart (we could not figure out a way of avoiding this).

Some of my favorite work that happened on this cycle is the effort to improve our multi-browser support, work towards supporting WebKit and Opera is underway and will improve over time. This work benefitted from our own work to support both Firefox 2.0 and 3.0 in the plugin.

Windowless mode (the mode that allows blending of HTML content and Silverlight content) is vastly improved but is only available on Firefox 3.0. This is a feature that is used extensively by Silverlight designers.

More details from the release:

• Webkit loads the plugin (kangaroo, lewing)
• The stream/downloader/request/response logic (used for downloading media) has been been almost entirely moved from the browser bridges into libmoon, with the browsers providing subclasses. (kangaroo, sde)
• Finally add argument checking to all wrapped plugin objects (fejj).
• Windowless mode fixes (lewing, toshok)
• Plugin event handling fixes (lewing)

Hanging out at Microsoft

I will be at Microsoft on Thursday and Friday, and only have meetings on Thursday afternoon.

I would love to meet other hackers. If you want to meet, discuss, talk, drop me an email: miguel@novell.com

oh. hai.

People at the office became LOLcat fans by reading every day i can has cheezburger a few months ago. It was harmless entertainment.

But recently I have discovered that LOLspeak has started to creep into our codebase.

Consider the IHasSourceView interface or the ActiveSourceCanHasBrowser property.

What other naming conventions should we adopt?

Discuss.

Office Justice, at Last!

For the past few weeks, since Aaron Bockover found out that some of us like Twix. He then bought all the 70 cent twixes in the vending machine at the office and started reselling them for a dollar.

Michael struck back by bringing fruits and vegetables today. To which Aaron replied "I hope those fruits rot".

Today the machine was refilled:

This has brought finally an end to the empire of speculation from this rapacious market meddler. With at least 12 new twix bars injected into the local office economy we should enjoy a smooth sailing for the rest of the week.

Update: Some sources inform me that Aaron was trying to create an artificial scarcity in the office by buying the remaining 12 twixes, he hit a glitch in the machine, he got two bars for the price of one.

This is not bodding well for the local Twix aficionados:

Update 2: Capitalism knows no limits:

Update 3: To add insult to injury, he is now selling individual Twix bars for 70 cents each, or a full pack for 1 dollar.

Update 4: We will be picketing Aaron's office at 4pm this afternoon:

LinuxHater's blog, I am a fan

I love the LinuxHater's Blog. This is a must-read RSS feed.

It is funny in a way that xkcd is funny to Unixers. Whoever is writing that blog has extensive experience on Linux and enviable writing skills.

A first class grilling/roasting of Linux and the Linux community. It should help keep things in perspective.

Some good starting points:

• At least we don't have any viruses.
• On Linux Audio.
• Good Software Isn't Really Free.
• How to write a Gnome Application and a KDE application.

OpenOffice-based applications with Mono and MonoDevelop

The entire OpenOffice suite is built on top of a component technology called UNO (which is inspired by COM, but heavily extended). Pretty much all of the functionality in OpenOffice is exposed through some UNO interface, and although the native interface is built on top of C++ many bridges have been created over the years that expose UNO to a variety of languages, runtimes and object brokers.

A few years ago, Sun implemented a .NET bridge for UNO. This bridge allowed .NET developers to script, extend and reuse open office as a library from C# or any other .NET language.

A couple of years ago, Michael Meeks and the OpenOffice community ported the bridge to work with Mono which allows developers to create OpenOffice based solutions using any of the Mono programming languages (C#, Boo, IronPython, IronRuby, F#, VB, Nemerle and so on).

But even if the engine existed, it was not properly installed in the system and getting a C#-based OpenOffice solution required lots of Unix skills, the kind of skills that would likely be in short supply by those interested in OpenOffice automation. We fixed this in this last development cycle, so now a Novell OpenOffice installation will have everything you need.

Michael Hutchinson, one of our MonoDevelop hackers has put together the missing pieces to simplify the process. He has created the solution templates necessary to create these solutions, and packaged them as a Mono.Addin for exiting MonoDevelop users.

To build OpenOffice solutions, you need to install the OpenOffice addin for MonoDevelop. To do this, follow these steps.

Activate the Add-in Manager

Select Templates.

Select the OpenOffice Automation Samples

Complete the installation for the Mono.Addin, once you are done, create a new Solution:

You can skip this step, and get back here later, but you might want to select "Unix integration":

Take advantage of code-completion:

This is what the default sample looks like, you can use this as a foundation for your program. Since this is a COM-based API, it is not an API that is easy to discover with code-completion popups, so we figured it was best to ship full working samples:

Build and run your application by hitting F5:

Your OpenOffice solution in all of its glory, this is from the samples that we distribute as part of the templates:

Improving the OOo API

Sadly, the OOo API exposed by UNO does not look or feel very .NET-ish at all. It is a COM-based API and is not very discoverable. Code-completion will sadly not be of much help without the samples.

Additionally, the conventions used in the code are not very .NETish, so it will feel a little bit odd.

There are a few options here, we could either massage the .NET exposed API into something more .NET-friendly, or we could create a wrapper around the UNO API for most common usage scenarios. We are not sure what would be best.

We believe using a Cecil-based tool-massager we could rewrite the cli_types.dll library to get a more .NET-ish API:

• Rename classes and methods to follow the casing conventions for .NET.
• Turn setters and getters into properties.
• Change the XBlah convention into IBlah convention for interfaces.

This still leaves the issue of interface identity to be solved where an underlying object that always implements IA, IB and IC interfaces is usually only exposed as one of those interfaces, and you must do an explicit cast to the other interfaces to access the other features.

Thanks to the Michaels for all the hard work.

Gnome-Do 0.5: "The Fighting 0.5!"

Another beautiful desktop application, this one by David Siegel. I have become a fan of it in the last few months since David started working on it:

Gnome-Do is another very polished application, one that shows a lot of love and care for taking care of the small details. David just released a new version a couple of days ago.

Gnome-Do is inspired by Quicksilver from MacOS and like Banshee, it uses Mono.Addins extensively to make the application more useful:

Go to David's page for more details and screenshots on all the new features (Skype, Flickr, Twitter, IM, Google Calendar integration; community plugins, configuration and more).

Banshee 1.0 is out.

Banshee the Gtk#/Mono based media player for Unix has finally reached its 1.0 status.

Congratulations to the Banshee team for this release!

This is one of the finest applications built with Mono, Gtk#, GStreamer, Mono.Addins, DBus#, C# and Boo. The Banshee developers have worked very hard in creating a very polished UI and have paid a lot of attention to the smallest details to provide an enjoyable user experience.

This really should be considered Banshee 2.0 as SLED shipped two years ago with Banshee 0.10, which was already a stable product.

Since that first public release, a lot of work went into improving the user experience by making Banshee faster and cope better with large libraries. This required new custom Gtk# widgets (these are reusable widgets, with a model-view-controller system, and part of the Banshee Core) as well as rethinking the way that storage was handled by pushing as much work as possible to the SQLite layer and never loading all the data in memory.

The full list of the features will give you a better idea of what this player can do.

Plugin Architecture, a Foundation For Experimentation.

This is an architectural overview of Banshee's Core:

Banshee is split up in various components, but most importantly the core does very little work. Pretty much all of the functionality for the media player is implemented as Mono.Addins. Mono.Addins provides services that allow users to install new extensions for Banshee to add new features to the core.

To make it simpler to develop plugins we will be shipping MonoDevelop and VisualStudio templates to get developers started on creating new plugins for Banshee.

For example, Alan McGovern, the creator of MonoTorrent a bittorrent library for Mono and .NET extended the Podcast functionality in Banshee to download your podcasts using Bittorrent (this extension is not part of the 1.0 release).

In this screencast you can see how a download for a Democracy Now podcast goes from 1.5k/s to 650k/s (OGG, low-quality WMV).

Windows

In the next couple of weeks we will package Banshee for Windows to expand the reach of Banshee to more users. And as part of this distribution we will also distribute templates for Visual Studio developers to create their own extensions.

Unity3D now available for the Wii

Unity3D has announced that their game creation tool is now available for Wii developers. Unity lets you script your games in Boo, Javascript or C# with Mono.

Congratulations to Joachim, David and the rest of the team at Unity3D for getting this working.

More Gtk# Widgets

I had forgotten about Medsphere's LGPLed Gtk# widgets, the Medsphere Widgets.

Today Brad blogged about them.

This is my favorite:

Wow. Adobe Buzzword

I am blown away by Adobe's Buzzword web-based word processor.

It feels like a great native application, with great widgetry and lots of attention paid to the details.

Custom Controls in Gtk# Article

CodeProject has a nice article by Olivier Lecointre on how to write custom Gtk# controls.

Sample widget from the article.

Oliver writes:

I recently made the switch to Ubuntu and I am quite delighted with it. I develop mainly on .Net and my dependence on some Windows tools was the sticky point that made me wait this long. This is now not really an issue, thanks to the great work of the Mono and MonoDevelop teams, and the related libraries like Gtk#, Cairo and Pango.

Mono brings the .Net platform to Linux and MonoDevelop offers a good alternative to Visual Studio, making the development of GUI applications on Gtk desktop almost painless.

I wrote a cooperation tool that I use on a daily basis and my first goal after the switch was to port it over with Mono and Gtk#. After a few adjustments caused by the fundamental differences between Windows.Forms and Gtk#, I have to admit that the port of the application was a lot easier that I initially thought; I replaced the UI controls by widgets, set the various forms to use the Gtk# layout, and that is pretty much it. The rest of the non UI code worked as expected with an overall good performance.

An area that gave me the most difficulty was the usage of custom controls with a behavior that is different from the base Gtk components. This is the focus of this article.

Holly Gtk Widgets

Daniel has announced his "Holly Widgets" for Gtk#. A collection of useful Gkt# widgets. The widgets also support MonoDevelop/Stetic integration.

The code is available from http://code.google.com/p/holly-gtk-widgets.

Picker screenshots:

Font picker.

Date and time picker.

Color picker.

Nice extensions:

Baloon Tooltips.

Regular expression validating entries.

IP address entry.

Combo box with file system navigation.

Simplified API wrappers:

A simple combobox.

A simple list (avoids TreeView binding, and supports Measure/Draw on a per-item basis).

Simplified tree view API.

Combo box with tree view.

Daniel also has nice samples and documentation for all of his new widgets.

Mono Embeds Nabble

Mono has always been developed on mailing lists like pretty much every other classic open source project. But many of our younger or migrating users are more used to Web-based forums and have always wanted to have a forum-like interface for the Mono mailing lists.

Thomas Wiest and Joseph Hill have just finished the integration Nabble into the Mono web site. Now people can access all of the Mono mailing lists with a Forums UI.

Messages posted in the forum will go to the appropriate mailing list (either hosted at lists.ximian.com or groups.google.com), and messages posted on the mailing lists get reflected on the forums.

You can access the forums http://www.go-mono.com/forums here.

Summary

Message View

Enjoy!

Games Worth Playing

As you might know, I do not consider myself a gamer although I now understand the Penny Arcade cartoon.

I have done my best in the past year to increasing BestBuy and Game Stop share holder value by dumping thousands of dollars in my quest to be entertained by video games.

The games that I actuall enjoyed playing are very few:

• Wii Sports, but the fun fades away after a couple of months.
• Metroid Prime 3, on the Wii, fantastic controls.
• Ratchet and Clank on the PS3, incredibly fun.
• Bioshock on the xbox360, by far, my favorite game.
• Ratchet and Clank on the PSP, just because I love the PS3 version so much.
• Sudoku on the DS.
• Update: I forgot the incredibly fun Simpsons game.

I continue to refuse to play propaganda games and do not enjoy sport games, racing games or fantasy games. I could not get into the games in the Orange Box, even if everyone loves it (Portal was ok). And I have not tried Rock Band or Guitar Hero because I do not want to have a drumset ont he living room.

I guess I like games that have a developing story and are not very repetitive.

Is there anything like Bioshock on the game pipeline?

Silverlight 2.0 Hello World

Silverlight's 2.0 deployment model changed significantly from the 1.1 alpha model. In the past you would load a XAML file, and then on demand load any managed libraries referenced from the XAML file before parsing could continue.

With Silverlight 2.0 the model has changed. One of the downsides is that now you deploy things as a ZIP file with a manifest file which feels obnoxious. On the upside, the loop "try-to-parse-or-keep-requesting-files-from-the-browser-until-all-dependencies-are-downloaded" is now gone. Now you get a zip file asynchronously, unpack it, load all the assemblies in the zip file, create an instance of the class specified as the entry point, and off you go. No more latency.

This hopefully also solves an obnoxious pattern that was common in 1.1: calling createFromXaml from Javascript could hang execution while Moonlight waited for the browser to fetch a missing assembly.

This week Silverlight 2.0 said hello in Linux:

This corresponds to the standard template with the content of the user control set to a TextBlock.

There are some peculiar patterns in Silverlight 2.0 instantiation model. Instead of creating objects from a XAML description, an object of a known-type is first created, and then the object is initialized from a XAML file. Your object is supposed to call LoadComponent ("my-xaml-definition") to initialize itself.

Google IG and Sudoku

A few months ago, am not sure how, but Nat talked me into getting a widescreen laptop. I no longer remember what were the touted benefits of it, but this warpig of a machine is both buggy and heavy.

Since the warpig is just too heavy to carry home every day (and also requires a base station hooked up to high-def output to stay at 2.4 GHz of speed) I just leave it at work and use my five year old computer at home to surf the internets. When I bought the machine I remember distinctively describing it to friends as "a silent computer". Five years later every time I load a new web page the fans make as much noise as the construction site across the street. Was I deaf back then, or did the fans become dirty and loud?

I am a fan of Google IG, and recently I discovered that they have a tiny IDE that you can add to your Google IG page. So I decided to try to write a Silverlight Sudoku application entirely using that tiny editor in my old computer at home:

I actually cheated a little and used Emacs here and there every once in a while.

But I ended up with this cute Sudoku/Silverlight application that has exactly one puzzle:

I am very proud of my one-puzzle Sudoku because it has some of the features that I like from Big Bang's Sudoku (click to flag, double click to set the value, hints) and some cute and simple animations that I wrote in xaml and shows my allegiance to the clean and simple configuration religion:

I published it on IG as "Moonlight Sudoku". To add it to your IG home page, go here and click "Add to Google".

Now the only problem with it is that it seems to work just fine with Firefox but seems to have problems with IE and Safari. I must be doing something wrong with Javascript, but I have no idea what it could be. If you can find the bug, let me know so I can make it work on other browser.

My toy sudoku only has one puzzle, this is clearly a design decision to prevent people from becoming addicted to Moonlight Sudoku. But if you know of a source of http-fetchable Sudoku puzzles, let me know, as I might want to revisit this design decision to include more puzzles.

You can download the self-contained module (ig + html + xaml + js) from here. You might also need the Silverlight.js file.

In clear violation of David Mamet's advise to the aspiring actor, I am now going to act surprised:

In other news, Firefox 3 RC1 came out, and the release notes have nothing to say about the bugs that prevent Silverlight from working with it.

Moonlight - Full Packages Available from Packman

Larry Ewing pointed this out.

PackMan now has full packages of Moonlight for OpenSUSE users (it includes ffmpeg codecs).

You can use these packages to check some videos at channel9 or see the dual-stream updated videos from Mix 08. Keep us posted about bugs and limitations.

Mono's Winforms 2.0 is now API Complete

Jonathan Pobst has posted the update on our Windows.Forms 2.0 work.

Some interesting points from his blog entry:

• We are now API complete, which means that our public API is exactly the same as .Net's (all 12,776 methods).
• The first check-in to our current Winforms implementation was on July 8th, 2004. It took 4 years to get here, and 6,434 individual SVN commits.
• The toolkit is made up of 115k lines of code.

Also:

• We currently have three backends: X11, OSX and Win32.
• There is a Google Summer of Code effort to improve our theming and OS integration this summer.
• Winforms 2.0 will also debut support for XIM to allow input for CJK character sets.
• We have a nice binding to Gecko as our implementation for WebControl which we started last year (currently we are limited to Gecko on X11 though, no Mac support yet for this WebControl).
• The Desktop team at Novell is adding UI Automation and accessibility support to Windows.Forms integrating it with Gnome's ATK. They have a full team dedicated to that goal.
• R-to-L support: It is not an priority for us at this point, but it would be nice if someone with RtoL needs were to complete the work that Sebastien did last year to use Pango inside GDI+.

Winforms 2.0 was the last piece of code holding off the Mono 2.0 release. We anticipate that there will be bugs, so we want to encourage folks to submit their bug reports and to evaluate the portability of their sofwtare using our Mono Migration Analyzer tool.

Congratulations to the Winforms team, and everyone that provided bug reports, test cases, contributed code, tested and worked with us to bring it to where it is today.

First Moonlight Release

Today we are making the first public release of Moonlight, supporting the Silverlight 1.0 profile for Linux. The release comes in two forms:

• No-media codecs supported, but easy to install: head to http://www.go-mono.com/moonlight and click on the cute installer for Moonlight. This currently hosts builds for Linux x86 and x86-64 for Firefox.
• Source-code compilation, but you can optionally compile FFMpeg codecs yourself. To do this, download our moon-0.6.tar.bz2. And follow the build instructions.

Update: I apologize for the confussion; This is not Moonlight 1.0, this is the first source code release that we are making of Moonlight for interested contributors and developers. This release is not even a Beta release, as we are not yet feature complete (missing components in media codecs, the media pipeline, as well as fixing about 70 known bugs). Apologies for any confussion.

Although Moonlight works on Firefox 2 and Firefox 3, recent changes in Firefox 3 prevent Silverlight and Moonlight from working (For details see #432371, #430965). There is a user contributed Greasemonkey script that will work around this bug for some sites (requires Greasemonkey).

Windowless: Moonlight supports "windowless" mode, a mechanism that allows Silverlight content to blend with other HTML ements on a page. This is only supported by Firefox 3, users of older versions of Firefox might run into Silverlight applications and web sites that do not work correctly as many Silverlight applications depend on this functionality (Flash sites have the same problem with Firefox 2).

1.1 and 2.0 support: This release only supports the Silverlight 1.0 profile. The 1.1 support is no longer maintained and the release happened at the time when we are transitioning the APIs to 2.0.

If you find bugs, please file them for us to fix.

Cross-platform, standalone Silverilght Applications

Tamir Khason published an interesting approach at hosting standalone Silverlight applications.

His solution is a Windows.Forms application that hosts a Windows.Forms.WebControl and inside the WebControl he hosts Silverlight.

Unlike my proposal for standalone Silverlight Applications that is currently Moonlight-specific (and currently limited to Linux/X11) this approach works on Windows with .NET and with Linux using Mono and Moonlight:

Left side: .NET hosting WebControl and Silverlight on Windows; Right side: Mono hosting WebControl and Moonlight running on Linux.

In addition to hosting the WebControl for hosting Silverlight, a thread is running to dispatch http requests locally using HttpListener. HttpListener is an embeddable HTTP server that is part of the class libraries, and exposes a very limited API. You can host ASP.NET with HttpListener by doing the bindings by hand, or you could use our Mono.WebServer library (part of our XSP/mod_mono distribution) to allow your applications to have a fully hosted ASP.NET server.

Mono.WebServer is what iFolder uses to embed the ASP.NET server to expose SOAP-based WebServices to clients.

Of course, this currently does not work on MacOS X as we do have no implementation of WebControl for Windows.Forms on OSX, something that a contributor might want to look into.

You can get the source for the sample from Tamir's page.

Consulting Gig at Novell

We are looking for consultants to work on a six to nine month project at Novell to write a prototype for a Visual Studio addin in C# or C++ that will connect Visual Studio and its debugging infrastructure to a remote Linux machine running Mono and the Mono Debugger.

If you are interested in working with us in this project, you must have good C# and C++ skills, experience with networking and protocol design, knowledge of COM and assembly language programming are pluses.

We are looking to bring two consultants for the duration of this project. If you are interested, please click this link and attach your resume, pointers to some existing projects of yours and so on.

Rodrigo Kumpera Completes the Mono Verifier

Rodrigo Kumpera, one of our VM developers has completed the instruction verifier for Mono's virtual machine. This effort started in June of last year.

The verifier is a late addition to the Mono VM as it was not a priority to run untrusted code inside the virtual machine.

But as Mono user base grew, it became important to support this feature. Second Life needs this to run potentially malicious code that is uploaded by a user, and we need this to provide an execution sandbox when running Moonlight on the browser.

Rodrigo did this work in stages: the first stage was to add support for the 1.0 virtual machine opcodes. Once that was done, verificiation for the 2.0 generic instructions was added.

This is an important milestone in our support for Silverlight 2.0 support on Linux.

Congratulations to Rodrigo for his work!

Mono and the Google Summer of Code 2008

This year Mono is participating again on the Google Summer of Code. A list of the applications that were accepted is available at Google's page.

This year the quality of the applications and the new ideas submitted (aside from those we proposed) was fantastic. They were too good, and it was very hard to select the final projects (we wanted to pick 33 of the 75 projects proposed, but there were only 15 slots available).

LinuxersForObama

Linuxers, BSDers, FLOSSers, GNUers, OSSers, Mysqlers, Gnomers, KDErs, Monoers, Javaers, PHPers, I invite you to donate to Obama through the LinuxersForObama campaign hosted at My.BarackObama.com web site.

If you are a US citizen, or a legal immigrant (green card holder), you can contribute 10, 20, or perhaps 2,300 to the Obama campaign.

You can donate here http://my.barackobama.com/page/outreach/view/main/LinuxersForObama.

I called the campaign "LinuxersForObama" because its short. I know it should have been called "GNULinuxBSDApacheX11PythonPerlMySQLPostgressPerlRubyJavaRailsMonoForObama", but it was getting hard to type.

And if you are a Windowser or Mac()er, but you like how Linuxers stick it to the man, feel free to donate to my LinuxersForObama campaign.

In retrospect, I should have created one campaign per product, and use that to settle once and for all, which is the best FLOSS project.

Standalone Silverlight Applications

Last year we created a framework to run Silverlight applications as native applications. At the time we called those applications moonlight desklets.

The desklets are Silverlight applications that run in standalone mode, with full access to the entire Mono API stack (as opposed to be limited to the .NET subset for the web) and that can optionally render without frames. This is a screenshot from three desklets running on Linux from last year:

Beyond hack-value, there are in my opinion many reasons why this is valuable. Powerful .NET programming model, powerful graphics and animation framework, reuse the same code base for Web and desktop development, and a sandboxed execution model.

Many people have asked us privately about this.

The Magical mopen Command

To run a standalone desklet, all you have to do run the mopen command, like this:

	$ mopen ruler
	

The above command will look for a directory called "ruler" listed in your PATH, and if the file default.xaml lives inside that directory, it will open that file up. This XAML file can in turn reference managed code.

We did this so applications could be deployed in directories, very much like they are deployed on MacOS. The rules are simple, applications should be self-contained, keep all their data relative to their executable base directory, the foundation for this started with our application deployment guidelines.

It also draws inspiration from the bundles from MacOS X and the `open' command there.

How does this work? Lets consider our enterprise pixel measuring tool, the Moonlight ruler, which is made up of two files:

• default.xaml, the basic XAML container, it references the managed code in ruler.dll
• ruler.cs contains the code to draw the ruler.

This is what it looks like when you run it:

Awesome Moonlight desktop ruler.

Details

At LugRadio Live this weekend in San Francisco I decided to turn my Mono talk into a Moonlight talk, and I discussed some of the things that we have been doing with Moonlight.

Let me start with this artist rendition of Moonlight's Core:

The orange pieces were built by the Mono/Moonlight team at Novell. The green pieces are provided by Microsoft (and only for use in the browser context, we will get back to this later) and the blue stuff is stuff that we consume from the community.

The Moonlight Core provides the high-level canvas, the XAML loading, the animation framework, timers, media streaming and demuxing and event dispatching. It also has very few dependencies, it uses Cairo to render graphics and interfaces with our media pipeline and needs codecs to do video (currently ffmpeg if you build from source, or Microsoft's when we release).

Our engine today has three frontends:

The most important one of course is the plugin front-end, the one that is embedded into Firefox and renders the Silverlight content.

The other front-end is a Gtk# widget, a simple Gtk+ host that embeds the Moonlight Core into a widget and allows developers to embed any kind of XAML content (including managed code) inside it. I did a demo of Banshee embedding a grid of video players at LugRadio.

This is a widget that can be used to spice up your application. If you feel that you need some bling for your application, some gratuitous animations and special effects, the GtkSilver widget can help you. Using it is trivial:

	using Gtk.Moonlight;

	[...]
	void SetupWidget ()
	{
		Application.Init ();
	
		GtkSilver surface = new GtkSilver ();

		surface.LoadFile ("MyAnimation.xaml");

	        
		Window w = new Window ("Demo");
		w.Add (surface);
		w.ShowAll ();
		Application.Run ();
	}
	

If you want to get a handle on specific objects, you can just use the FindName method on the surface's canvas:

	MediaElement handler = (MediaElement) surface.Canvas.FindName ("MyVideoPlayer");

	// Start playback.
	handler.Play ();
	

And the third interface is the fabulous mopen command that we previously described (which is conveniently implemented on top of GtkSilver; yes, we know, we are geniuses).

The Two Stacks

As you might suspect from reading about GtkSilver and the browser, the Moonlight managed stack (that is, the C#/.NET APIs) actually comes in two shapes:

• Browser API: This is what people creating Silverlight applications are familiar with. Its a subset of .NET 3.5 and it has limitations as to what you can do: no local file system access and a sandbox that encapsulates all the actions of Silverlight applications.
• Full API: We also offer the full API, this is our implementation of .NET 3.5 that has been augmented with the Silverlight APIs.

As you can guess, GtkSilver and the desklets today use the Full API; And our browser plugin uses the more limited Browser API and the security sandbox.

We will get back to this soon.

Adobe Air

Adobe AIR has a great experience for installing native applications on your system, and they are cross platform (Windows, Mac and Linux).

I found a cute twitter application built with it, and have been a happy user of it for a few weeks (see screenshot).

I have no idea how extensive the AIR APIs are, whether they are sandboxed or whether they provide full access to all the APIs like our Moonlight Full API provides, but you can build some cute desktop applications with it.

I like it.

Silverlight Desktop Apps

Part of the reason why our Desklets did not evolve much in the last year was because there were no controls for them. You could build your own, but that was a lot of work, and it was hard to share, and most importantly, everyone knew that Microsoft was going to ship controls for Silverlight.

Now that controls are part of Silverlight 2.0 and that most of the high-level controls have been open sourced and that they are incredibly powerful and great to skin it makes sense to think again about native desktop applications using Silverlight.

We as a team can certainly create a Linux-only platform for these controls, and live happily with mopen, but we would miss an opportunity of having something cross platform like AIR is.

Ideally, Microsoft would follow our direction and implement and distribute the same mopen functionality that we have for Windows and Mac. This would ensure maximum adoption of standalone Silverlight-applications.

In a less ideal world, we (the Mono/Moonlight community) could port Moonlight's mopen command to Windows and MacOS, but with none of the power of influence that Microsoft has.

Directions and Challenges

Michael Hutchinson has suggested that we should have an minstall tool in the same spirit of mopen. This tool would take care of installation on each platform, creating shortcuts, desktop links and using the right icon.

Moonlight currently runs on systems with Cairo, and requires Gtk+ for event processing. It might be interesting to get it running on Win32, OSX and others with the tiniest footprint possible (bundling Gtk+ for Windows and MacOS for native apps sound large).

Another alternative is to use Microsoft's Silverlight on Windows to implement `mopen' as opposed to porting Moonlight. Apparently its possible to instantiate it through COM in some form, but that would still leave OSX out.

The codecs that Microsoft will distribute for use with Moonlight are limited to use inside the browser. This will prevent Moonlight's standalone applications from playing back any vc-1, wmv, wma, mp3 content.

We could add OS-specific codecs; On Linux we could call into Fluendo's commercial codecs, on Windows and Mac use the system codecs.

But we could also standardize on free video and audio codecs for the desktop edition: add support for the free video and audio codecs (BBC's Dirac, which will become VC-2, Vorbis and Theora).

We are currently busy doing Moonlight 1.0, and then we will get busy doing 2.0. So we will not be able to spend time on any of these projects for quite some time, but these are projects that developers in the community could work on or companies interested in pushing Moonlight in that direction.

Discuss.

Mono C# compiler now also MIT X11 licensed

I know, so exciting, a license.

We are dual-licensing under this uber-liberal license because:

We are changing the license to allow parts of the compiler to be reused as part of MonoDevelop, our LINQ class libraries and to embed it in ASP.NET.

In MonoDevelop: This will allow the compiler to be used to improve code-completion to support C# 3.0 as well as improving the heuristics when offering completions. This will reuse the front end and parts of the backend.

Compiler hosting inside ASP.NET: This will embed the whole compiler into the ASP.NET process, eliminating about one second for each compilation of a piece of code. In the past, for each request for an uncompiled resource, we would have to call the compiler, wait for its output and then load the output. This typically shaves between 0.7 to 1 second on those scenarios, ideal to improve the developer experience.

LINQ Class Libraries: This will allow us to reuse parts of the compiler in our System.Core implementation for LINQ for the current 3.5 generation and upcoming generations. Many corner cases are handled by the compiler, and we will now be able to lift those pieces. This will mostly use the backend of the compiler.

Detailed InvalidCastException Goodness Comes to a VM Near You.

When you perform an invalid cast in Mono (trying to force one type into another with a cast) or JIT would throw an InvalidCastException. If you are lucky, you would get a line number (compile with -g, run with --debug), but if you had a complicated expression you would have no idea what the problem was.

A few weeks ago, in support of Marek's growing pains in tracking down some bugs, Zoltan checked in support for a new feature in the Mono runtime: --debug=casts. Now, When you pass this option to the runtime, it will report the type that you are trying to cast. This feature is not activated by default as it generates more code, and consumes more memory.

This sample:

	$ cat demo.cs
        class Test {
                static void Main ()
                {
                        string s = "hola";
                        object j = s;

                        object d = (Test) j;
                }
        }
	$ mono demo.exe

	Unhandled Exception: System.InvalidCastException: Cannot cast from source type to destination type.
	   at Test.Main () [0x00000] 

	$ mono --debug=casts demo.exe

	Unhandled Exception: System.InvalidCastException: Unable to cast object of type 'System.String' to type 'Test'.
	  at Test.Main () [0x00008] in /tmp/demo.cs:10 
	

Awesome.

Generic Code Sharing: Good and Bad News

Mark Probst has been working for the past few months on adding support to the Mono JIT to support generic code sharing. This is a technique that allows the JIT to share the same code generated for two differently instantiated types, for example:

	class Stack<T> {
	    T [] data = new T [10];
	    int top;
	
	    public void Push (T t) { data [top++] = t; }
	    public T    Pop  ()    { return data [--top]; }
	    public int  Count      { get { return top; } }
	}

	class Test {
		static void Main ()
		{
			Stack<long> ls = new Stack<long> ();
			ls.Push (10);
	
			Stack<Test> ts = new Stack<Test> ();
			ts.Push (new Test ());
	
			Console.WriteLine ("Count={0} {1}", ls.Count, ts.Count);
		}
	}
	

The JIT must generate different code for the actual Stack instantiation, one must contain a pointer (32 bits on 32 bit machines) and another one must contain 64 bits. So the structures are different in memory, and so is the implementation for Push and Pop.

But certain methods do not depend on the datatype sizes (for example) and could be shared regardless of how their container type is instantiated.

Mark posted the Good news, the bad news and his strategy to deal with the bad news. Am going to limit myself to the good news, and you can click on the link and read the thread for the bad news:

Now for some interesting statistics.  Apart from the runtime's test
suite I've used three other test suites/benchmarks, namely IronPython
(running pystone), Nemerle (compiling its own compiler) and FSharp
(compiling and running a Hello World program).  Here are the
Good-News-statistics.  The numbers given are "no sharing / sharing"
and have been collected on a 32 bit system:

IronPython
  Methods compiled: 3614 / 3368
  native code space used: 719k / 691k

Nemerle
  Method compiled: 7210 / 6302
  native code space used: 2001k / 1943k

FSharp
  Methods compiled: 15529 / 11431
  native code space used: 2193k / 2062k
	
	

See his post for the rest.

Update: Mark informs me that the "bad news" that I conveniently left out of this post (memory consumption in FSharp for bookkeeping was 600k of memory) has now been fixed.

The 600k of bookkeeping in the FSharp test has been now turned down to 14k. So we can scratch that "bad news" part. Congratulations Mark!

Open Source Powershell Implementation

This weekend ath the Code Camp in Waltham, Igor Moochnick announced the release of pash his open source power shell implementation. It currently runs on Linux, MacOS, WindowsCE and Windows.

pash on Linux.

Igor's project is hosted on sourceforge.

A few years ago Ryan Paul from Arstechnica wrote a nice guide to powershell (when it was still called Monad Shell).

OOXML: The Wins

Regardless of where you stand on the outcome of OOXML becoming an ISO standard, it is worth pointing out that the opposition to OOXML pushed Microsoft into more open directions.

If you are sulking because OOXML was approved, it is worth looking at what actually was accomplished since December of 2005 when the process begun.

Before OOXML came to ISO and the global review of it begun:

• Microsoft moving away from their proprietary file formats to open, and XML-based (easier to manipulate, produce and consume) file formats.
• Novel raised a record number of issues on the specification, many of which were solved before the spec was approved by ECMA.
• About 700 pages worth of descriptions for the formula specifications (one of the major issues from our end when we joined ECMA TC45 in December of 2005).
• The OOXML specification placed under the OSP.

Once OOXML went for discussion at ISO, a number of good things came out and are major community wins:

1. The specifications for the old binary file formats were published under the OSP (February of 2008).

2. The above documents were backed up by the British Library in case Microsoft ever stops publishing them (announcement).

3. Microsoft is funding the development of a translator between the old binary file formats and OOXML which should assist folks that have experience in one format and want to understand the other, or just want to convert documents back and forth. If your app lacked support for OOXML, but had support for the old formats, you can use these tools.

4. Microsoft agreed that future versions of OOXML will be covered by the OSP a concern that some people had about future versions of the document.

5. Microsoft pledged to modify future versions of Office to implement the ISO version of OOXML.

6. working group was created to look into harmonization of OOXML and ODF, something that many developers involved in office suites have been advocating for a long time.

7. Microsoft pledged to support features to support other file formats as native file formats in their office suite:

Last year we sponsored a translator project that gave people the ability to read and write ODF files from Microsoft Office. Last month we announced that we would update the Office product so that the ODF translators could natively plug into Office and give people the same options they get from the other file formats. People will be able to set ODF as the default format in Office if that's what they want by simply installing the translators and then changing their settings.

8. Lots of clarifications went into the spec, and people should be happy about that.

9. And finally, now that OOXML is an ISO standard, as Patrick Durusau implied there are many winners.

Anyways, I wanted to keep this short and uplifting, this seems like a win for everyone all around.

Preemptive-reply-to-the-above-paragraph: I will not reply/approve any flames, FUD or half-truths.

I love Reddit Captions

OOXML, looking forward

I have been reading the OOXML storm in a teacup for more than a year now. Am looking forward to the approval of OOXML as an ISO standard and to be able to move the discussion back to the things that actually matter: free and open source software.

For a year, countless bytes have been wasted on what is now a very difficult plot to follow, specially for people that have not followed it since the start (or as Bill Maher said last week "Its like trying to make sense of a LOST episode". Note: am a Lost fan).

When we go back to what matters, we should be ready to ask IBM to open source its Lotus Notes software based on Open Office (as staunch supporters of open formats, and open source, I think its in their best interest to do so). There are nice components in Lotus Notes that would be nice to integrate into the upcoming OpenOffice 3.

But most importantly, it is a time for all of those strong advocates of open standards to stop talking, and start walking. I look forward for all that energy that went into discussing the pros and cons of OOXML to join an open source project and start contributing code, documentation, support, create support forums, file good bug reports and help us make free and open source software better.

In case you have not been noticing, Apple is gaining market share on the desktop. Some of our own kernel hackers, desktop hackers, web hackers that used to be Linux or BSD users are flocking to the proprietary OSX.

We need to change that, lets reverse that trend, and lets focus on what actually matters: the free and open source desktop. To make this happen we will need all the help that we can get.

Punditry and lobbying will not get us very far, real work will.

Mono: 2008 Google Summer of Code

The Mono project will be participating once again in the Google Summer of Code.

Although some ideas from various teams are available in our student projects page this year, I want to encourage students to feel free to submit ideas that they think should be done with Mono.

In past years, a handful of students suggested their own ideas as to what would be an interesting project to work on during the summer, we liked those and turned those into full fledged projects.

Feel free to suggest a project that you think would be useful to the Mono community, and to discuss your idea with us in the Mono Summer of Code IRC channel: #monosoc on irc.gnome.org

Documentation: Generics and CSS

Mono contributor Jonathan has been hard at work and has added support for Generics to Monodoc as well as importing the ECMA documentation for the new generic APIs.

Monodoc now also support man pages (we have a handful now, and we will later add all the mono ones) and we now render using a CSS stylesheet instead of the collection of gross hacks that we used to have.

Check the new docs out.

Pastor Wright

From Dave Winer's blog:

Melroy Hodge, from Queens, NY, a contact on Twitter, sent a pointer to a YouTube video of a longer excerpt of Jeremiah Wright's post-911 sermon, one of the speeches that soundbites were shown repeatedly on cable news this week. I guess it's not surprising that the cable news excerpts gave a very misleading impression. (Next time this happens we must do an immediate fact-check.) http://www.youtube.com/watch?v=QOdlnzkeoyQ

This is a must-watch video. Stop what you're doing, right now, and watch it.

I found myself captivated by Wright's ideas and the way he expresses them.

I agree with everything he said.

I would have been willing to cut him some slack, because this was less than a week after the attack, and those were crazy days, who knew what was coming next. But he was right, we have done what they did to us, and we're doing it again in Iraq. The US was led by despotic people and we followed; we wanted to punish someone, anyone, and it didn't matter if they had anything to do with what happened to us. And we did.

Read the whole post from Dave Winer's blog. The video as he says, is a must-watch.

Also, from the twitter-o-sphere:

OOXML SDK

Microsoft is working on a OOXML SDK for managed languages. They have announced a roadmap:

Being selfish here, I would love to see this SDK relreased under an MS-PL license myself, I think it would be great to get folks outside of the Windows world consume and produce OOXML files easily.

This is a win-win for everyone. Microsoft gets more products consuming and producing OOXML documents on the Windows and MacOS worlds through Mono, and we get a great API to use on Linux with .NET languages.

Although I have emailed a few friends, am not sure am reaching the right people inside Microsoft. I would love to discuss the advantages that MS-PLing the code base would have.

It has to be under a license like the MS-PL as opposed to just a license to use and distribute on Linux for this code to make it and be distributed eventually into Linux distributions.

Dog Whisperer

We became fans of the Dog Whisperer TV show from the Discovery Channel in the past few months. Sadly, we are unable to have a dog at home, so we might look for a new place.

My friend Shelly pointed me to Gladewell's article on the New Yorker about Cesar Milan, just as fun and interesting as watching the show.

Mono Debugger, now with 2.0 support

Last week, Martin Baulig announced that the debugger in trunk adds supports to many 2.0 features, our last major feature missing in the debugger.

The biggest news is that the debugger now has support for C# 2.0
features such as generics, anonymous methods and iterators:

  * We can currently print fields in generic instances, print their
    types and parent classes.

  * Recursive generic types (see test/src/TestRecursiveGenerics.cs for
    an example) are supported, but need more testing.

  * There is some limited support for method invocations, but we can't
    get their types yet.

  * Support for anonymous methods and iterators should now be pretty
    much complete; we can fully access captured variables etc.

To try out the updated debugger in trunk, you must use Mono from trunk. With this code in place, we have now started the work to integrate it into MonoDevelop.

MonoDevelop 1.1 (due in six months) will have support for the debugger.

Remote Debugging

Additionally, Harald announced that they have modified the Mono Debugger to support remote debugging (useful for debugging embedded systems for instance).

They wrote a detailed document on the architecture for their remote debugging framework.

Their work is now licensed under the MIT X11 license, which will allow us to integrate this directly into the Mono and Mono Debugger distributions.

Banshee Release

Yesterday Aaron released the first preview of Banshee 1.0, the Digg-o-Sphere does an in-depth review of the release announcement:

This is what Banshee looks like:

Banshee on Linux.

In other news, thanks to the work of Scott, Banshee will soon be distributed for Windows as well:

Bringing open source media players to Windows.

Banshee uses Lluis' Mono.Addins framework to allow third party developers to extend banshee with interesting new features.

MonoDevelop 1.0 has been Released

After a few years in the oven, we are ready to announce the first release of MonoDevelop. Lluis has put together a set of in-depth release notes that covers the major features available in MonoDevelop and links to various tutorials and screencasts as well as extensive screenshots of what is available in MonoDevelop 1.0.

MonoDevelop 1.0 is designed mostly for Linux developers creating Gnome and ASP.NET applications but MonoDevelop is also available for MacOS users that download our Mono installer and will still be useful if they are building Mono-based applications on OSX.

The IDE has many of the features that you would expect from a modern IDE for Mono: support for programming in multiple languages, an extensible design, editors and designers for ASP.NET and Gnome applications, integration with Unix toolchains and Visual Studio Solutions, support for source code control and following standard Unix development practices, integrated NUnit testing, Unix Packaging and Deployment (following the GNU conventions, and Mono conventions for libraries and packages), internationalization and localization, tools to maintain your project documentation and command line tools to access this functionality.

We have some pretty good language support in this release: C#, VisualBasic.NET, Java, C and C++. Check the previous link for the details as to how extensive the support is for each feature.

Some screencasts:

• Creating a Simple User Interface with MonoDevelop.
• Creating Custom Widgets with MonoDevelop.
• You wrote it, now you want to ship it, see how MonoDevelop can help you: Buildig Packages with MonoDevelop.
• Using Subversion to host your source code, see Using Version Control with MonoDevelop.

There is more documentation on MonoDevelop available as well.

The Early MonoDevelop History.

In late 2003, a few developers were looking for an IDE to write C# code in Linux, not something too fancy, but something that would provide Intellisense features.

Windows developers were used to Visual Studio, and Mike Krueger and the developers at Alpha Sierra Papa had created the very successful SharpDevelop project, a .NET Windows.Forms-based application. At the time, Mono did not have a working Windows.Forms implementation (it would take another three years before our official 1.0 release of Windows.Forms) so this ruled.

Although there had been an attempt to make SharpDevelop portable by Mike (with a variation on the theme of Eclipse's toolkit) this effort had not been completed, and SharpDevelop continued to be a Windows.Forms application.

Pedro Abelleira first extracted the editor and intellisense engine from SharpDevelop into a standalone component that rendered using Gtk# instead of Windows.Forms. This was back late in 2003. Initially it was only going to be a text editor.

Development started mostly on irc and quickly contributors started to porting various other pieces from SharpDevelop or rewriting the GUI components with Glade and Gtk#. By late 2003 Todd Berman had taken over the maintenance duties of MonoDevelop and sent me a email on December 31st:

Oh, and we are shooting for eating our own MonoDevelop dog food by the end of this coming weekend, and it looks like we will be there even before then.

History of the GUI Designers

As regular Gnome developers were were very happy using Glade and Gtk#'s [Widget] attributes to bind the XML GUI representation to our own variables. You double clicked on the .glade file, and Glade would launch from within MonoDevelop, you would tweak your UI, save it, and rerun from MonoDevelop.

Around this time Dan Winship from the desktop team started working on a new GUI designer for Gnome, the Stetic GUI designer. This was a Gtk#-based GUI designer, and the idea is that this could be embedded in other applications. An early screencast of Stetic capabilities is available here:

Stetic in March 2005.

Work continued, but Dan eventually moved on to other projects. By the end of 2005 we were looking at integrating a GUI designer directly into MonoDevelop and Stetic was not ready to do that, so instead Lluis integrated Glade-3 into MonoDevelop:

MonoDevelop with Glade-3, January 2006

This project did not live for too long. Glade-3 had to be patched, and we quickly realized that all the features that we wanted would require more than trivial changes to Glade-3. So we decided that instead of investing time in the C code base and the bridge to C#, that we would complete Stetic which was entirely written in C#, this is what it looks like today:

Stetic Designer inside MonoDevelop.

A complete screencast of Stetic and today's MonoDevelop integration shows all the work that Lluis and his team did to provide a smooth editing experience.

Today MonoDevelop not only supports forms design, but it also provides menu and toolbar editors and support for managing your icon collection in your application.

Menu editor

A key feature of .NET is the creation of reusable components. Lluis brought this to MonoDevelop and the stetic editor. This screencast shows how to create widget libraries with MonoDevelop and Stetic that you can later reuse in your projects or in other projects.

The Future

The team has already started work on the next release of MonoDevelop, version 1.1. Our goal is to release new versions of MonoDevelop every six months. To do this, we are planning on doing all of the disruptive changes on branches, and always keep our HEAD revision stable.

There are a number of incremental improvements on our task list, but also some exciting new features. There were many things that we could not get in time for 1.0 are being incorporated or implemented since the 1.0 tree branched a few months ago. Some of the new features that trunk users or alpha testers can get include:

New Managed Editor: The text editor is now entirely managed and has many new features like configurable keybindings (Really nice Emacs keybindings), split windows, Emacs/Firefox-like incremental search on a toolbar (no more annoying dialog box popping up in the middle of your source code) and one of the most requested features: region folding.

Moving to a fully managed widget written in C# gives us a lot of flexibility to improve the editor. This is a theme that was consistent in the 1.0 release, moving from Glade to Stetic and moving from the GdlDock to our own managed dock paid off every time in terms of developer agility and features that we could implement.

ASP.NET editor: new improvements will provide auto-complete and intellisense while editing .aspx files. Also, with the maturity of WebKit/Gtk we are hoping to replace Mozilla as the GUI editor for ASP.NET pages with this.

Integrated Debugging: Currently the Mono Debugger is only available as a command line tool. Our next release of MonoDevelop will provide debugging directly from the IDE.

Windows Port: There is now a Windows profile release of MonoDevelop. This will be great for developers that are building applications using Gtk# on Windows and want to get access to the Stetic GUI designer which currently requires them to use Linux to do this. It is not our intention to compete with SharpDevelop as an open source IDE for Windows Programmers although there might be some overlap.

msbuild-based model: We want to move to the Visual Studio build model to improve interoperability with Visual Studio, Blend and SharpDevelop and other tools that use msbuild files as their interoperability layer. This will allow developers to easily move across tools to work on different parts of a project.

XML Editor: A backport from SharpDevelop's XML editor has been integrated.

Future versions of MonoDevelop will extend on this feature set an integrate Ivan's Windows.Forms designer, Alan's Silverlight designer and improve Michael's ASP.NET designer.

Mono on the iPhone, video

This video shows the Mono C# compiler building a sample native ObjC# application on the iPhone and then running the resulting executable on the iPhone.

Pay special attention to the beautiful error messages that our C# compiler generates.

This is using the ObjC# bindings that provide access to the Objective-C APIs from C#.

Discussion of the bindings and the Cocoa# APIs takes place in the cocoa-sharp and mono-osx mailing lists.

Update: better version, this one the typing with two hands and with some widgets on the screen and some events hooked up:

See Geoff's Norton for more details and also this one with comic included.

Of course, the iPhone is a locked platform, and chances of people being allowed to run Mono seem low.

The real question is when Android will be open enough that we can do a port of Mono to it (there is no C SDK at this point for Android).

Mix 08

Just got back from Mix 08 in Las Vegas. It was good to catch up again with old friends and make new friends. As usual, the event was a blast. To me the big interesting news were Silverlight 2.0 and the ASP.NET MVC release (details at Phil's blog).

Ray's keynote was light on the details, and too abstract for my taste.

The IE8 announcements were interesting. Their contributed test suite for CSS is good news, and came up with two nice new features: activities and webslices. Both ideas and their specifications were released under the OSP, and apparently by the end of the day there was a Mozilla plugin that implemented Activities. Hopefully we will get WebSlices on Linux as well.

Of course my personal favorite were the Silverlight 2 updates.

Since I attended mostly the hallway session, am using this weekend to catch up on the actual sessions. But I loved Joe Stegman's presentation on Silverlight 2 which Mike Harsh described as "we wanted to show code, not slides, lots of examples; you know, developer porn".

Sadly, I could not make it back to Part 2 with Mike, as the room was full and the bouncers were turning people away (and I also missed the repeat the next day).

Office Ribbon

If you love the software that you build, Jensen Harris' presentation on the History of the Office Ribbon is probably the most inspiring talk I have seen in years.

Every developer building GUI applications should listen to this presentation. This is as inspiring as Joel's articles on UI design were a few years ago when we were working on GNOME 2 or Andy's focus on empowering users were back on the Eazel days.

Silverlight 2

First things first. Catching up with Silverlight 2 is a great place to get demos, samples, tutorials, presentations and in-depth coverage of what is new in Silverlight 2.

Silverlight 1.1 consisted of a .NET binding on top of the core Silverlight 1.0 engine and the addition of the DLR and DLR-based languages. This was never intended to be the last word on it, and it was mostly a showcase of things to come.

Silverlight 2 is the evolution of the 1.1 model in a number of directions.

The distribution model: Possibly the most interesting change is that there is now a "core" of Silverlight that will be available on every system and a model to bundle extra libraries for Silverlight. This keeps the Silverlight 2 download small, but most importantly it means that Silverlight 2.0 can ship without having to complete and freeze the APIs for every possible feature that people want.

The "extras" collection of controls are delivered in this way (like the databound controls) as well as things like the DLR. This means that you can use the DLR today, and still allow the DLR and Iron* teams to continue working and improving it without locking developers to an old version of the DLR that would have been deployed with every 2.0 installation.

Some other important changes:

• The application model is more consistent, and some of the common usage patterns for applications are directly handled by the new model (download all assets at once).
• A control framework. In 1.0 and 1.1, every developer had to create his own control framework, with 2.0 the control framework is in the core, and there is a nice collection of standard controls available (with text input!).
• Styles: The control framework also allows for skinning of controls through XAML snippets. For instance, consider a button, there a number of states that a button is rendered as: focused, unfocused, pressed, not-pressed. To transition from one to the other you can specify a XAML storyboard that will transition the button from any state to any other state. And you can also controls what is rendered, and how, independently of the control itself.
• Seadragon images. This is the support to quickly download images and implement infinite zooming. See this TED presentation for the details and a nice demo.
• Networking: support for socket connections (there are many restrictions here on what can be done) and support for allowing clients to issue HTTP requests to other web sites (this is similar to Flash policy files for the same feature).
• Updated DLR and Iron*.

Open source Silverlight Controls

At the keynote Scott announced that the high-level Silverlight controls were going to be open sourced, they will be released under the MS-PL.

There was apparently a miss-understanding and the controls were released inadvertently under a more restrictive license, but both Scott and Brian confirmed that they wanted us to use those controls.

This is brilliant, not only because it helps us, but for a load of useful reasons: it will let developers learn how to write controls early on the Silverlight 2 release process and