ross-platform software development means different things to different people. For many programmers immersed in Microsoft languages such as VB.Net or C#, the real test comes down to creating a Windows Forms-based application in one of those languages, compiling it to MSIL, and running the resulting EXE file on the desired target platform, such as Linux or OS X. The Mono project is getting close to making that dream a reality.
The Mono project has tried at least three different approaches to implementing Windows Forms on Linux. The first implementation attempt tried to map Windows Forms to the Gtk toolkit. But that was an impedance mismatch. Trying to map equivalencies between two separate GUI toolkits didn’t work well?and would have required an installation of Gtk+ on the target machine. The next attempt would have required the Wine Windows emulator. While that worked after a fashion, it was slow, buggy, and setting it up properly required many steps. This wasn’t exactly the “copy a file over and run” scenario desired by most developers.
With Mono 1.1.4, the project has made the transition to a native implementation of System.Windows.Forms. Quoting from the Mono Web site:
“System.Windows.Forms in Mono is implemented using System.Drawing. All controls are natively drawn through System.Drawing. System.Windows.Forms implements its own driver interface to communicate with the host OS windowing system. Currently, we have a driver for Win32, for X11, and a driver for native Mac OS X support (no X11 required). The drivers translate the native window messages into WndProc compatible messages, to provide as much compatibility with native .Net as possible.”
While the latest version (1.1.7) is getting closer to full parity with the .NET 1.1 framework’s Windows Forms features, there are still some pretty big holes, such as incomplete or absent version of the DataGrid, RichTextBox, PrintPreview, and other controls. According to the Mono roadmap the project’s goal is to be feature complete with the release of Mono version 1.2 in Q3 of 2005. Mono 1.2 will also include assemblies from Whidbey (Visual Studio 2005) as technology previews, adding full compatibility with the .NET 2.0 framework to later releases.
The primary Mono Web site has recently converted to a Wiki format using the MediaWiki engine. You’ll find links to download the latest version of the Mono runtime and updates on the overall progress of the project. For specific information on Mono’s Windows Forms implementation check out their site. There’s also a site dedicated to Windows Forms development primarily from the Windows perspective; but many of the examples on that site run on Mono as well.
|Author’s Note: I used Mono version 1.1.7 running on Novell Linux Desktop to test the sample code developed for this article.|
Testing Mono’s Windows Forms
One good way to test the progress of Mono’s Windows Forms is to compile and run some of the sample code from Microsoft’s Visual Studio help files. I gave this a shot for a number of different examples, including one for the DataGrid. Running the DataGrid demo confirmed that it still doesn’t work?although it doesn’t crash, and you can examine some of its properties.
Another good test is to try out some of the open source projects out on the net. The Mono guys did just this for a demonstration at the recent Brainshare conference in Salt Lake City. To give it a good test they downloaded the TerraDemo Windows Forms demonstration program, made a few changes to accommodate non-working controls (such as the DataGrid by changing it to a ListView), compiled the source with Mono, and ran the project. The result was a pretty amazing demonstration of multiple controls including the TabControl, ImageList, StatusBar, and more. TerraDemo also makes heavy use of Web services to communicate with Microsoft’s TerraServer Web site. Fortunately, the ASP.NET portion of Mono, including Web services support, has been solid for some time already. You can download the changed TerraDemo files here.
But unless you can quantify everything your applications need, perhaps the best testing method is to just start coding and see what happens. That approach can be frustrating with this release if you don’t know where the holes are. For example, creating the sample code for this article required more than a few hours trying to work around some of the limitations of the controls as implemented. The goal was to build a simple program with a few controls using VB.NET in Visual Studio 2003, generate an EXE file, copy it over to the Linux machine, and see if it ran. To help ease the pain, you can check the Mono Windows Forms status page to find out the status of your favorite control.
Build a Sample App
The Mono Windows Forms Web site has a section dedicated to tracking the implementation progress of the various controls. You’ll also find a link to download the latest version of the System.Windows.Forms.dll file for Linux. To use the new file you must execute the following commands as root from a terminal window:
# gacutil -u System.Windows.Forms # gacutil -i System.Windows.Forms.dll
This method should work as long as none of the supporting file versions have changed, which typically happens only after a point release.
Data binding to most controls works fine (with the exception of the DataGrid). To test this out I created a simple program that reads a list of birthdays from an XML file, binds the last names to a list box, and displays the first name and date in separate combo boxes when users select a name (see Figure 1). This application also uses the FileDialog control to open and save the XML file.
|Figure 1. Birthdays GUI: The birthday tracker application has a pretty simple interface and functions almost identically on Windows or Linux.|
Public Class Form1 Inherits System.Windows.Forms.Form Public dsBirthdays As New DataSet Private Sub btnReadXML_Click( _ ByVal sender As System.Object, _ ByVal e As System.EventArgs) _ Handles btnReadXML.Click Dim openFileDialog1 As New OpenFileDialog openFileDialog1.Filter = "XML Files|*.xml" openFileDialog1.Title = "Select an XML File" ' Show the Dialog. ' If the user clicked OK in the dialog and ' an .XML file was selected, open it. If openFileDialog1.ShowDialog() = _ DialogResult.OK Then dsBirthdays.ReadXml(openFileDialog1.FileName) lstNames.DataSource = dsBirthdays.Tables(0) lstNames.DisplayMember = "LastName" End If End Sub Private Sub lstNames_SelectedIndexChanged( _ ByVal sender As System.Object, _ ByVal e As System.EventArgs) _ Handles lstNames.SelectedIndexChanged cmbName.DataSource = dsBirthdays.Tables(0) cmbName.DisplayMember = "FirstName" cmbBirthday.DataSource = dsBirthdays.Tables(0) cmbBirthday.DisplayMember = "Birthday" End Sub Private Sub btnQuit_Click( _ ByVal sender As System.Object, _ ByVal e As System.EventArgs) _ Handles btnQuit.Click Application.Exit() End Sub End Class
Testing Other Controls
The Calendar control and the DateTimePicker control work well on both platforms. Another simple application created for testing purposes calculates the Julian day from a selected date and displays it in a text box. You can use this same control in an ASP page with Mono’s XSP tool or Apache with mod_mono.
Imports System Imports System.Globalization Public Class Form1 Inherits System.Windows.Forms.Form Private Sub Button1_Click( _ ByVal sender As System.Object, _ ByVal e As System.EventArgs) _ Handles Button1.Click ' Creates and initializes a JulianCalendar. Dim myCal As New JulianCalendar TextBox1.Text = myCal.GetDayOfYear( _ DateTimePicker1.Text) End Sub End Class
|Figure 2. Julian Day Calculator with DateTime Picker: This Julian day calculator uses the built in JulianCalendar class to determine the day number with one line of code.|
Not Fully Baked
Mono Windows Forms has come a long way since the initial release, and it’s certainly possible to get started creating applications today, but you’ll want to wait for the 1.2 release to make a realistic assessment of Mono’s full capabilities. Still, this version shows clearly that cross-platform Windows Forms applications will be a reality in the near future.