Java Still the Ugly Duckling

I had heard that the Windows look and feel had been improved in the more recent releases of Java, so I decided to download the developer’s kit for the Java 1.5 Release Candidate and have a look myself. In the true JDK tradition, a number of impressive samples accompanied the kit. The 2D sample demonstrates smooth animation, clipping, composition and a number of other effects.



The old Swing set demo was also present. Curious about graphical and behavioural changes, I quickly selected the Windows look and feel to see what, if anything, had changed.



At first glance, the interface looked a lot like other Windows XP applications. However, menus did not render with the user-selected effect (in my case smooth fading), and MDI child windows felt slow to move around. This suggests that Swing retains its custom drawing routines and still does not map to the standard Windows controls. I think this is unfortunate, because nothing annoys me as much in user interfaces as applications that just don’t quite “feel right”.
I know a lot of people feel that the Swing library was over-engineered. I was never particularly bothered by the class design in Swing — on the contrary, the flexibility and elegance appealed to me. I think if Sun would have aimed for an ambitious mapping to the Win32 API right from the start (I do not count AWT as “ambitious”), they would have had a winner on their hands. As it is, I feel like they missed the boat. I’m not going to weep anymore about what could have been, and should have been. Instead I’ll just continue happily using the .NET Framework whenever and wherever I get the chance.

Good Bye, FreeBSD

A few weeks ago I replaced FreeBSD on my old server box (Pentium II 350 MHz) with the first test release of Fedora Core 3. FreeBSD had been serving me very well for years, happily protecting my Windows machine with its native firewalling and NAT capabilities, as well as providing limited server functionality with virtually no downtime (the occasional power outages provided the rare exceptions).

Meanwhile, the open-source alternative to Microsoft’s .NET framework, Mono, had been making steady progress. It had finally reached a stage where I felt it deserved serious testing (read: playing with). Unfortunately Mono is not well supported under FreeBSD due to some architectural issues that I’m not familiar with in detail. Thus, it seemed my only option was to explore a Linux based distribution.

Having used Debian briefly in the past, I felt tempted to select that operating system again. However, Debian in my experience required quite a lot of time to set up in a satisfactory way, in part due to the ever-present package dependancy nightmares that most Linux distributions suffer from in varying degrees when complex software packages like desktop environments enter the picture. I decided, instead, to give the latest Fedora Core release a test run.

I downloaded the DVD and burned it — the installation went flawlessly, and I was greeted by a nice graphical login screen. Although I’m a bit of a KDE fan, I decided this time to install only GNOME to conserve disk space. GNOME is, I believe, better supported under Mono at the present time than KDE is.

As you may be aware, Fedora Core is a popular community developed operating system based on Red Hat. Back in the days of the last Red Hat releases, a decision was made to improve consistancy across desktop environments by providing default settings and themes in both KDE and GNOME to deliver a uniform user experience. This is something I took issue with and I am still not entirely happy with this decision, even though in general I applaud efforts to improve usability and consistancy in Linux. Nonetheless, as this was to be my server box — sitting alone in a cupboard — the user interface was of minor importance.

Fedora Core provides a number of useful applications for configuring common services, such as Samba and FTP. This went fairly well. I had no time or desire to learn how Linux managed firewalling (having invested significant time doing the same for FreeBSD once), and chose to use the excellent graphical configuration tool known as Firestarter. It provides nice wizards and dialogs to configure IP masquerading (NAT) as well as packet filtering. As Firestarter launched, it output a message in the console from which it was launched to the effect of having detected NETFILTER. I was somewhat concerned that this was a non-standard firewall tool, but as was pointed out to me, iptables is actually used for the filtering. Within a matter of minutes, the firewall was configured the way I wanted to (with appropriate port forwarding) and Firestarter had automatically modified the rc.d init scripts in order to auto-launch during each boot-up. After minor hurdles, I also had Samba up and running for easy file sharing between my Windows XP machine and my FreeBSD machine.

I was now anxious to install the software I was interested in — Mono, in particular. I initially tried the traditional route; using rpm. I had downloaded all of the Mono packages and tried to install them one by one. Unfortunately, my worst fears came true — a number of packages were missing and the installation could not continue. I then discovered another option for package management which had surfaced on this platform in recent years — YUM. YUM is an automatic package dependancy resolver and downloader. With minimal effort, I was able to download Mono from their YUM repository. The next step was downloading MonoDevelop to provide a somewhat nicer interface to Mono and its documentation. Unfortunately a dependancy problem surfaced again, but after a quick Google session I was able to find a solution (which involved re-installing the Mono packages — again, using YUM). I finally had Mono up and running and could not resist compiling an Hello World application and try to run it in Windows. It worked flawlessly! I then tried the opposite — compiling another Hello World in Windows to run it in Linux using the Mono run-time. That, too, worked great.

Layout Hurdles

I first read about MyXaml months ago on OSNews (the successor to the great BeOS related news site). It’s an open source effort to provide an XML based object instantiator similar to Microsoft’s upcoming XAML (to deput in the next Windows release Longhorn). Although MyXaml is not tailored to work with any particular types of objects (as long as they follow some rules), it was primarily devised — as was its inspiration XAML — for use with user interface specifications.

I have not yet played with MyXaml but I am delighted that we do not have to wait for Longhorn to use XML in .NET applications. However, it’s quite tedious to have to keep track of the absolute position and size of controls. Something that really stunned me was the fact that Microsoft chose not to include tools for dynamic layout management, similar to those provided by countless frameworks before such as AWT/Swing in Java, MUI and BGUI in AmigaOS and XUL in Mozilla. Those frameworks allow developers to specify the relative position and size of controls in a cunning way — by grouping controls into nested hierarchies where special layout managers manage child controls. Java’s BorderLayout is a particularly powerful example — by nesting objects managed by this layout manager, it is possible to specify a user interface of almost any complexity.

In early 2001, as part of an engineering thesis, I set out together with a friend to create the under-pinnings of a simple platform-independant widget library with dynamic layout facilities (with proof-of-concept implementations provided for Windows and MacOS). We decided at the time to call the library BORG, for Basic Object-oriented Responsive Graphics (the name was not at all inspired by Star Trek, we promise!).

I feel tempted to dig up the old source code and provide similar layout managers for .NET. I have a feeling that something like that, together with MyXaml, could be a killer combination. Thankfully Microsoft has had the foresight to provide hooks for layout management in the .NET framework.