Thanks to Pedro Santos I got a full list of the Mono Brainshare PPT files:

• Introducing Mono for Developers [ppt];
• Advanced Mono Development: Best Practices [ppt];
• Mono: Developing and Deploying .NET Applications for Linux [ppt];
• Mono: Rapid GUI Application Development on Linux [ppt];
• Developing ASP .NET on Linux with Mono - ainda n�o h� o ppt dispon�vel
• Using Mono to Develop the Next Version of Novell iFolder [ppt];
• Developing with the System.DirectoryServices Namespace API for Mono [ppt].

Notice that the slides that Erik and myself used were slightly different than those that we published for the event, as we continue the long tradition of `Redo your presentation the night before'.

Nat just posted the official Novell position on the toolkits

I just posted this to Slashdot:

As Nat has posted elsewhere, the Heise article is wrong.

My team and other teams within Novell continue to develop and use Gtk as their toolkit (recently open sourced Simias/iFolder for instance) and all of the Mono GUI development tools.

The only use of Qt that am aware of today is SUSE's recently open sourced YAST.

Btw, if you have been following my posts on my blog and on the desktop-devel-list, you will know that my feeling is that all of the existing toolkits today (Gtk, Qt, XUL and VCL) will become obsolete and we need to start looking at the next generation toolkit system.

Next Generation Toolkits

One of the interesting aspects of Avalon is that they built the widget set on the equivalent of Gnome's AA canvas. Canvas and Canvas items. They call them `FrameworkElements', but it is the same model: once you "paint" something, it stays there (link)

Nautilus had a branch that had some more advanced canvas items than the ones we ship in libgnomecanvas: Andy had written some canvas items that rendered tiny visualizations of a web page, so "web page" links would update live.

Novell LDAP for Mono

Sunil has an amazing tutorial on using the Novell.LDAP library for Mono. To find, go here and search for "DirectoryServices" on the Title. Sorry, the direct link fails.

In a few more hours Erik and myself will be doing the Mono components of the Friday keynote at Novell's Brainshare event.

In spite of his race, that man is extremely valuable to me. He is not some random dingbat I found on the Strip.

You can watch the keynote live tomorrow at 9am MST or you can wait and get the archive.

We'd be fools not to ride this strange torpedo all the way to the end.

The Gnome Users in Spain (host of the largest Linux deployment today) are having the "GUADEC Hispana", their Gnome Users and Developers Conference for the Spanish speaking developers on the 21-23 of May in Almedralejo, Spain.

Chris Stone just announced that Novell will be moving the whole company to OpenOffice by the end of the year, and to Linux on the desktop a year after (I did not see the graph clearly).

iFolder and Simias (A metadata-based file system, with built-in synchronization) have been Open Sourced as well, and you can check it out here. Simias is similar to Longhorn's WinFS and i tis built on Mono.

Nat just demoed the desktop, with iFolder/Simias to share and synchronize the data between a Windows machine and a Linux machine and demostrated the Groupwise support for Evolution and Gaim.

Havoc, you are skipping over the fact that a viable compromise for the community is not a viable compromise for some products, and hence why you see some companies picking a particular technology as I described at length below.

The community can go XPCOM/PyGtk if they choose to (btw, same legal problems apply related to patents on COM ;-), but it is unlikely that the larger projects will pick on this.

You are right that a "wrapper" could encapsulate Longhorn. But I think it will be a useless effort.

No ISV will pick a layer on top of the Longhorn layer on Windows today or tomorrow: .NET is simple, easy to use as opposed to older APIs. ISVs will demand native support for them.

Perl and Python directly support COM and .NET APIs today for interop. Am sure others will agree that why wrap everything in Longhorn, when you can just use your favorite language interop to use those features?

As I said, I still believe that the "Open Source Desktop Components" is a better way of going, more than the "Linux-based Open Source Desktop".

Underestimating Longhorn: Also, we should not under-estimate Longhorn. This is not a traditional OS anymore. This is an OS, that exposes .NET APIs as well as plugin interfaces for classes at every layer of the stack: file system, synchronization, transactions, communications, presentation and a miriad things more. "Wrappers" will hardly cut it here.

Not surprisingly, I think that Mono is the best possible path for ISVs: it allows them to share plenty of code (not all of it if they are aiming at "perfect" integration) between the various platforms with a high-level programming language. With a runtime environment that will let developers take advantage of the APIs in the major market.

On Fragmentation

So the core of Havoc's thesis can be summed up as:

We need to avoid fragmentation as various Unix desktop companies pick up a platform to develop software.

Sun is a major Linux Desktop player that will never ship Mono, but is using Java. So we should use Java to avoid fragmentation.

Legal and technical details, while interesting topics, are not at the core of this debate.

Novell: At least from this side, there has not been a company mandate to pick Mono over Java for any projects. Individual teams and projects inside the company have picked up on its own merits: iFolder, F-Spot and a few other internal projects which are not public yet. Some other internal projects picked Java for their own efforts.

The community has picked up on Mono/Gtk for a few applications on its own as well, the Gnome Foundation had no saying on this.

In a few areas, we believe that we should use Mono, but avoiding a community splint is an important consideration to us. Our plans to adopt Mono on Evolution are on hold, as well as integrating Mono with OpenOffice (notice that OpenOffice already has hooks for .NET though).

Sun: I will just assume that Sun developers have enough experience, and visibility into Java, that to them it is a natural fit to pick Java for projects, and that there is some degree of company mandate to use it. Am assuming this based on the naming of their Java Desktop System.

Longhorn: Microosft jokes aside, an important consideration for some projects is the fact that Longhorn will be released, will get deployed and the OS APIs have switched from C/C++ to CLR-based API.

In the Longhorn world, APIs are no longer your C/C++ grandmother APIs. Every new API introduced for the operating system is built on top of .NET. If you want to take advantage of it, you must write .NET code.

Writing code in Java is nice for writing code that is portable and uses to the lowest common denominator. But living in this bubble is not an option on Windows.

So the rationale for using Mono in some cases internally has been the fact that in Longhorn, you will have to write code in C#. Even if we have to write different GUIs (like iFolder: it will have three implementations: Windows.Forms, Gtk# and in the future a Cocoa# based one), we still get to share a lot of the functionality below.

Maybe the community does not need this kind of functionality, but most ISVs will, and that I think is a pretty big setback for Java and its Java ways. To survive in the desktop ISV market, Java will have to break with the write-once-run-anywhere mantra, and deeply integrate with Longhorn's WinFX.

If I were Sun, I would be retargetting my JVM code generator on Windows to generate CIL and making sure they can use every single Longhorn API.

Who are we and what are we building?

I personally think that we should move away from the "Linux Desktop" view of the world, and more into the "Open Source Desktop and Components" (I first heard this idea from Nat a few months ago).

It may sound like a trivial difference, but it is not. As much as I love the Linux desktop, and as much as I love our tools, the most successful desktop components today are OpenOffice and Mozilla because of their cross-platform nature.

Windows NT, XP, MacOS X and Longhorn will be with us for a long time. The best possible outcome of open source will likely be a segmented market like 33/33/33 for the desktop market.

In my opinion Java, Swing, Gtk+ nor Qt address effectively portability to all these systems. And by that, I mean that you always end up with an alien application: either the look, or the integration into the platform is substandard.

Mozilla and Abi to a larger extent got this relatively close to right. The botttom line is: no technology today gives you transparent portability.

The best bet today is to share as much as possible on your "engine" and redo the OS integration components for each OS you support.

Forks

Today there is already a major fork on the road.

Audio/Video: Today we got Xine, GStreamer and Helix as platforms for doing audio/media playback with different angles on the problem and no clear way of uniting them any time soon. Not to mention all the different player-level components.

I would love to see a standardized C-based interface that every one of them exposed and allow people to pick one over the other. I for one am not excited about requiring 160 megs of GStreamer code on my machine to essentially play mp3s and CDs.

And having an interface for the above is probably more important than any amount of Gtk+, Java, C# or Python skin on top of it.

Office Suites: We got plenty to choose from here: OpenOffice (in my opinion the only contender for the next three years) and the two smaller open source solutions.

Still, when it comes to engaging the community and pushing in a single direction, we got half the Gnome community pushing for Gnumeric/Abiword. If we can not reach concensus at this level with the community, I think we are going to have a hard problem selling anyone into agreeing into Java or C#.

Ok, gotta catch a plane.

For those keeping up with the language debate in Planet.Gnome, am linking to Paolo's excellent second follow up on the subject. Paolo is not yet aggregated in Planet.Gnome.

Paolo touches on why the ECMA CLI VM is a better VM to pick and describes his gives his view on the patent risks.

Preparing for Brainshare

Am getting ready to attend the Novell Brainshare conference in Salt Lake City this coming week. This trip agenda is pretty packed.

Am doing two presentations on Advanced Development with Mono as well as attending plenty of meetings with users, customers and reporters. Am looking forward to demostrate some of the latest developments in Mono and MonoDevelop

Sadly, we are not bringing our SPARC to the show to demostrate it, as it is kind of heavy ;-).

Am doing a talk at a local users group, but I can not find the e-mail with the information for my presentation, so if you know what it is, please mail me the information.

Latest Mono Develop

Installed the latest MonoDevelop from CVS. It now comes with integrated Mono Documentation (from MonoDoc) and the Mono Debugger.

New Planet

Discovered Blogs at MSDN, fascinating stuff on all things .NET related. For those interested in tracking Avalon and XAML, you also should check out Longhorn Blogs.

Paolo has written some follow up comments to Havoc's language advocacy post today.

Iraq on the Record

A report on the 237 missleading statements made by the Bush Administration on the threat possed by Iraq is now available from the House of Representatives Web Site, it includes a nice PDF with the report and graphics and a searchable database.

Last night Zoltan Varga checked-in his last patches that complete the Mono JIT port to the SPARC (with Solaris). The system passes all of our regression tests, and bootstraps Mono from scratch.

We had support for SPARC v8 and v9 as an interpreter, and some early work had been started by Mark last year. Zoltan picked up on the job on the first week of February and got the port done in marginally more than a month.

With three JIT ports now (1 CISC, 2 RISC), most of the portability issues on the JIT must have been taken care of.

Edd on the Mono Meeting

Edd has written a fantastic article on the Mono Meeting. The Slashdot peanut gallery has initiated a flame-fest over the comment that to me C is dead.

Gnome Notifier

The Gnome Notifier is definitely not a production system, it is a toy that illustrates a simple way of sending notifications to the system (some other people have discussed this before. Ideally a more complete system would have a history mechanism, and a way of browsing/answering previous messages.

For example, the most annoying problem I have with GAIM (My Instant Messenger in GNOME) is that whenever there is an interaction (you got disconnected from a remote site, or someone added you to their buddy list) a pop-up window shows up. This pop-up window shows up in the middle of your typing and grabs the focus. If you are writing code, writing an e-mail or doing any other form of typing, you are likely going to accept whatever is the default button by mistake, as you press the spacebar. Not to mention that you will have to re-type a few letters.

What I would like is for someone to integrate that into the Panel in some form, patch Gaim and all the other offenders, and have a way of getting back all the pending notifications.

I believe strongly that the Gnome Human Interface Guidelines should incorporate notification patterns and practies in their document, the following comes from the UI talk at the Microsoft PDC where there is a nice classification of user interaction:

Spectrum of Interaction Possibilities, from the PDC

Very sad news this morning; An outrageous attack on Madrid. Speechless.

Gnome Notifier

This is a quick hack that I put together in December 2002, a small notifier that looks like the Windows XP notifier with a nice little scrolling thingie. Someone asked me today about this hack, so am uploading it here.

The notifier embeds HTML with a few small tags that get displayed.

The nice trick back then was that you can send notifications to it by changing a Gconf key. You can then send notifications using the gconf api from your favorite language or from the command line language.

To use it today, do:

$ gnome-notifier &

Then to do notifications, you call a command line tool:

It supports a cute little prefix "run:", which does the obvious:

notify is just a shell script that calls gconftool.

Ideally this would be incorporated in some form into the panel, and with a history mechanism, you could use that to replace things like Gaim's annoying notifications.

XAML

So someone has implemented a XAML-like stack for Windows.Forms. Just to be clear on the danger of XAML for the Linux desktop: it is not about the markup language being a problem: its about the fact that XAML developers would create XAML applications that are bound to the Avalon toolkit.

So it comes down to: No Avalon, no app.

Benjamin Wootton has been working on Mono's Code Access Security (CAS) support. CAS is a way of creating arbitrary "sandboxes" in the .NET environment. The idea here is to load and execute untrusted side-by-side with your trusted code code without compromising your application. Similar in spirit to Java's security model.

CAS is needed for the various "click-once" setups for downloading, running and updating applications over the web, but more advanced uses enable scenarios like running untrusted plugins in a trusted application (for instance, a file format importer downloaded from the network, or plugins for your application which you do not necessarily want to trust).

You can read his list of requirements here; The project status page (with all his patches to add CAS to Mono) and a screenshot of his Mono CAS Configuration tool.

Anonymous Methods in Mono's C# compiler

I have been working on anonymous method support for the compiler in stages. My latest patch for the curious lives here.

The first one was to implement the implicit method group conversions to delegates, that one allows you to write things like:

void Method ()
{
	button.Clicked += clicked_handler;
	...
}
void clicked_handler ()
{
}

The second stage was to handle anonymous method declarations inline, and move the body of the code into an helper method in a chunk like this:

void Method ()
{
	button.Clicked += delegate {
		Console.WriteLine ("hello");
	}
}

Until that point things were relatively simple, the next step was a lot more tricky, and it involved capturing local variables:

void Method ()
{
	int i = 0;
	
	button.Clicked += delegate {
		Console.WriteLine (i);
	}
}

The above code needs to be compiled into something like:

void Method ()
{
	Locals1 __locals = new Locals1 ();
	locals1.i = 0;
	button.Clicked += locals1.__AnonymousMethod1;
}

class Locals1 {
	int i;
	
	void _AnonymousMethod ()
	{
		Console.WriteLine (i);
	}
}

Things get more complicated when you add multiple levels of scopes to variables:

void Method ()
{
	for (int i = 0; i < 10; i++){
		int j = 0;
		button.Clicked += delegate {
			Console.WriteLine (i + j);
		}
		int z = i + j;
	}
}

The above needs to generate roughly this:

void Method ()
{
	Local1 locals1 = new Locals1 ();
	locals1.i = i;
	
	for (int i = 0; i < 10; i++){
		Locals2 locals2 = new Locals2 ();
		locals2.locals1 = locals1;
		locals2.j = 0;
		
		button.Clicked += locals2.AnonymousMethod1;
		z = locals2.locals1.i + locals2.j;
	}
}

class Locals1 {
	int i;
}

class Locals2 {
	Locals1 locals1;
	int j;

	void AnonymousMethod ()
	{
		Console.WriteLine (locals1.i, j);		
	}
}

So fairly tricky: the variable can be accessed from the method containing the anonymous method.

One of the trickiest parts is the process that guesses the return value for the anonymous method: it might seem like inference is at work, but in fact during the resolution process we know the type we requiere, so the compiler triggers the resolution of the inner block when it gets this information.

Another complex bit was that the resolution/emit phases of the compiler had to be completely decoupled (they were already partially decoupled) because it is necessary to identify any variables that might be captured before we can even generate the first line of the block.

The patch is my work-in-progress code, it can not be checked into CVS just yet, since it breaks the iterator support in the compiler, so that must be fixed first.

First Mono Summit

I need to finish my write up and post the pictures of the event, but that will come later ;-)

This week the Mono Novell hackers have met for the first time in Boston, and we have been discussing the various tasks that need to be completed for Mono 1.0 and 1.2. IRC has been relatively quiet, and the exchange of ideas and discussions in town have been great.

The good news: we are on schedule for the 1.0 release, with a very nice cushion to test things. The only areas that are going to be very close to the deadline are System.Data and System.Drawing.

We got a few folks explain their areas of work to the others (so far I attended the meetings on security, remoting and the debugging session).

Duncan has been leading the release engineering meetings and laying down a process for the ongoing builds, and the 1.0 release packages.

Martin, Mike, Todd and Daniel are busy working on a small surprise for MonoDevelop, that they are hoping to demostrate on the open house this Friday/Saturday.

Windows.Forms is alive again! Peter Bartok demostrated various applications working with the new Wine, and together with Jordi Mas, they are resolving the various rendering integration issues between Libgdiplus (cairo) and WineLib (Wine turned into a library).

XAML

I read with interest Edd's thoughts on XAML and a new UI for GNOME. I have been doing some small XAML tests recently, and it is a very easy markup to generate. As I mentioned before the issue with XAML is that it will be very attractive to developers to move from HTML to XAML, as it provides more control, more widgetry and is an extensible system.

The future of Linux on the desktop is in fact on the line: if enterprise developers and IT developers fall in love with Xaml for building their in-house applications it will marginalize again Linux on the desktop.

There are two views of how to solve this problem. The Nat Friedman view of building a matching system in the meantime: leveraging our existing technologies, or the Miggy-view, which is lets implement the Avalon/XAML API. I think we should pursue both paths.