On Avalon and a desire for competition
A note of caution to the reader: this posting may appear to be chock full of code names like in a corny spy thriller.
The next version of Windows, code-named "Longhorn" has three main sub-systems: presentation (code-named "Avalon"), data (code-named "WinFS"), and communication (code-named "Indigo"). Avalon consists of a new collection of classes added to the .NET framework in addition to a spanking new markup language [again code-named] "XAML" or Extensible Application Markup Language. The way I see it, XAML is meant to accelerate the demise of HTML by a few dozen years. It is similar in concept to the Extensible User Interface Language (XUL) from the Netscape/Mozilla camp. [I will not get into who copied whom. That argument is a never-ending waste of time and bandwidth and is best relegated to whine fests at Slashdot].
A typical application written to Avalon will end up using both program code as well as markup code. Everything you can do in markup you can also do in program code. But not vice versa. So let's look at a snippet of XAML markup:
This represents a Button element with a couple attributes. XAML tags are tied to the Avalon class library in that each tag such as 'Button' is actually a class and the attributes specified are actually properties of that class. For that matter any class with a public no-arg constructor and public accessor/mutator (getter/setter) methods [ or 'Bean' as we Java developers refer to them] qualifies as a tag in XAML. So the above code snippet can be redefined in C# as:
Simple eh? Microsoft in a master stroke has reduced Windows UI programming to this kind of idiocy. But wait, Visual Studio .NET will auto-generate markup with a few mouse-clicks and keystrokes. That's just perfect for all us poor sods who were frequently dropped on their heads by their parents. Java Swing developers will catch on fast to the panels, layouts and event handling model in Avalon.
No, I am not jumping onto the .NET bandwagon, now that I have drooled all over this page. So what is the point I am trying to make here? It is this: where's the competition? The mantra of simplicity is a great way to evangelize a development platform. Innovations like Avalon -- that provide simple solutions to tackle hitherto complex (not to mention cumbersome) problems -- democratize the developer community. My friend Miral Shah always said "Visual Basic is for housewives". Well, I don't know about that, but I certainly believe XAML is. [I am not being pejorative here]
Unless the Java and GNOME communities get in gear and do something about desktop solutions using Java, XUL, GTK+, Qt or Mono [take your pick], there will be no fitting answer to the elements of Longhorn. Mono is an open-source .NET clone being developed by Novell (Ximian). They are now trying to implement the Windows.Forms namespace into the Linux platform. I think it is a worthwhile idea but a sad waste of time. Microsoft controls the .NET platform and whatever these guys at Mono do, they will always be playing catch-up with Microsoft. Plus Microsoft has the ability to wire .NET to Windows and by extension 90% of computer users out there. The .NET technology is optimized for Windows and vice versa. Try beating that 900 pound gorilla with your fly swatter! Instead of making Linux more like Windows, they should be focussing on capitalizing on Linux's unique plus-points i.e. the initiative and innovation it has fostered in the fledgling open-source community. This cries for something more fitting than a lame platform port of your competitor's software. There are existing projects out there, that in a correct combination, can provide credible alternatives. Some events need to happen in order to build a semblance of competition:
It is time we had effective XML-based form and UI definition languages backed by powerful managed runtime environments. Welcome, Avalon! And hooray for choice!
The next version of Windows, code-named "Longhorn" has three main sub-systems: presentation (code-named "Avalon"), data (code-named "WinFS"), and communication (code-named "Indigo"). Avalon consists of a new collection of classes added to the .NET framework in addition to a spanking new markup language [again code-named] "XAML" or Extensible Application Markup Language. The way I see it, XAML is meant to accelerate the demise of HTML by a few dozen years. It is similar in concept to the Extensible User Interface Language (XUL) from the Netscape/Mozilla camp. [I will not get into who copied whom. That argument is a never-ending waste of time and bandwidth and is best relegated to whine fests at Slashdot].
A typical application written to Avalon will end up using both program code as well as markup code. Everything you can do in markup you can also do in program code. But not vice versa. So let's look at a snippet of XAML markup:
<Button Background="Silver" FontSize="10pt">
Demo
</Button>
This represents a Button element with a couple attributes. XAML tags are tied to the Avalon class library in that each tag such as 'Button' is actually a class and the attributes specified are actually properties of that class. For that matter any class with a public no-arg constructor and public accessor/mutator (getter/setter) methods [ or 'Bean' as we Java developers refer to them] qualifies as a tag in XAML. So the above code snippet can be redefined in C# as:
Button button = new Button();
button.Background = Brushes.Silver;
button.FontSize = new FontSize(10, FontSizeType.Point);
button.Content = "Demo";
Simple eh? Microsoft in a master stroke has reduced Windows UI programming to this kind of idiocy. But wait, Visual Studio .NET will auto-generate markup with a few mouse-clicks and keystrokes. That's just perfect for all us poor sods who were frequently dropped on their heads by their parents. Java Swing developers will catch on fast to the panels, layouts and event handling model in Avalon.
No, I am not jumping onto the .NET bandwagon, now that I have drooled all over this page. So what is the point I am trying to make here? It is this: where's the competition? The mantra of simplicity is a great way to evangelize a development platform. Innovations like Avalon -- that provide simple solutions to tackle hitherto complex (not to mention cumbersome) problems -- democratize the developer community. My friend Miral Shah always said "Visual Basic is for housewives". Well, I don't know about that, but I certainly believe XAML is. [I am not being pejorative here]
Unless the Java and GNOME communities get in gear and do something about desktop solutions using Java, XUL, GTK+, Qt or Mono [take your pick], there will be no fitting answer to the elements of Longhorn. Mono is an open-source .NET clone being developed by Novell (Ximian). They are now trying to implement the Windows.Forms namespace into the Linux platform. I think it is a worthwhile idea but a sad waste of time. Microsoft controls the .NET platform and whatever these guys at Mono do, they will always be playing catch-up with Microsoft. Plus Microsoft has the ability to wire .NET to Windows and by extension 90% of computer users out there. The .NET technology is optimized for Windows and vice versa. Try beating that 900 pound gorilla with your fly swatter! Instead of making Linux more like Windows, they should be focussing on capitalizing on Linux's unique plus-points i.e. the initiative and innovation it has fostered in the fledgling open-source community. This cries for something more fitting than a lame platform port of your competitor's software. There are existing projects out there, that in a correct combination, can provide credible alternatives. Some events need to happen in order to build a semblance of competition:
- GNOME must support Java via the GCJ open source virtual machine and even Sun or IBM's VMs. The GNU Classpath project must reach currency with the Java language specs [it is only a matter of time now].
- SWT (IBM's open source Standard Windowing Toolkit) is a platform-specific runtime that exposes widgets like text boxes, panels, and other familiar GUI controls to Java developers, but uses JNI to make native code calls to create and interact with those controls. SWT applications work across platforms (currently support exists for Windows, Windows CE, Linux, AIX, Solaris among others). IBM or the open source community can combine XUL and SWT to create an alternative to Avalon.
- Alternatively, extensions to the Swing API can be added to provide support for markup-based UI development. For all that people say about Sun, I trust it if anyone to pull something like this off, if they only stopped treating Swing like an abandoned child. Nothing significant has gone into that API in the past 3-4 years while Sun has been touting XML here there and elsewhere.
It is time we had effective XML-based form and UI definition languages backed by powerful managed runtime environments. Welcome, Avalon! And hooray for choice!
