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.

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)

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: [email protected]

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:

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.

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.

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.

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 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 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.