Skip to main content

On desktop app developers and using vi/emacs

Posted by fabriziogiudici on November 12, 2007 at 3:34 AM PST

I had different plans for posting on my blog today, but a failure to my ADSL connection that occurred a couple of days ago has prevented me from publishing to the Subversion repository all the stuff I was going to blog about (I'm on a sloooow analog backup connection). So let me post a talk-like blog, waiting for Telecom Italia to fix my connection problems (oh my God...).

Yesterday Joshua Marinacci blogged about "Why don't you ship Swing Apps", two years later. He described a list of past problems with Swing that have been partially or totally addressed, including - among others:

Swing apps are slow to build and Swing layout managers suck. Well, these complaints basically boil down to the lack of good visual tools, now addressed by the NetBeans form builder and greatly improved in version 6 with binding and the app framework. Check.

One of the comments below was:

Something that´s perceived as a general issue (difficult layout managers) cannot be solved with an "IDE feature" (Netbeans). Perhaps a way to improve the GUI building situation is not to tie it to Netbeans. Instead, create a "standalone" GroupLayout editor that would settle this issue even for the people using Emacs/Vi....!

Now I strongly disagree with this assertion. But first let me clarify some points to prevent commenters from going off trail. The "NetBeans form builder", formerly named Matisse, is a wonderful visual designer for Swing user interfaces. It is appreciated by lot of people, including the Eclipse guys. As you visually design your interface, it generates plain Java code using GroupLayout, which is just a standard, opensource LayoutManager (included by default in Java 6 and available as an extension in Java 5). Matisse also generates an XML file, which is not used at runtime, but without it Matisse won't be able to work again on that piece of user interface. While there's no "closed" stuff here (the format of the XML file speaks by itself and Matisse itself is opensourced), there is people that would like to manually tweak the generated code and keep on using Matisse. This could be a reasonable requirement, but I'm not going to talk on it now.

What I'd like to focus now is that I'm against the use of Emacs/Vi to design a UI interface.

I'm sure that the guy who commented at the Joshua's blog is able to design a hell of stylish interface with Emacs and Vi, but the average Emacs user isn't able to. And the problem is that Swing was responsible for a good deal of problems with Java user interfaces, partially including its ugly default Look and Feel, but now that these issues have been fixed since a couple of years I still see ugly Swing user interfaces made. The problem are now Java developers: clearly a lot of them miss the skills for designing cool user interfaces. It's not a professional problem of theirs: after all an engineer is an engineer, a graphic developer is a graphic developer. But an engineer with better tools can do a better job.

Let's look at what people working with other technologies are doing. I've recently taught a couple of JavaFX classes at a very interesting event, named FromAToWeb, where a lot of tracks were focused on Adobe technologies (Flex, Air). In one track, we compared a simple address book implemented in JavaFX and Flex (and AJAX too, but this is not relevant now). From a programming point of view, JavaFX compared fine (immaturity apart). What I noted is that the Flex version was a bit shinier than mine: there were gradients and some animations. Well, JavaFX can do those things, but I didn't have the time to code them by hand.

Maybe Chris Oliver, the creator of JavaFX, is a Emacs/Vi guy and he made some damned cool examples of JavaFX applets, but I wouldn't be able to do that with a plain text editor and I think the average developer wouldn't be able too. For instance, right in these days, I'm adding a bit of simple animations in some blueMarine panels (simple stuff, such as components that enter the scene sliding). I'm using TimingFramework which takes care of almost all the boilerplate code, but I still have to manually integrate it with my components and - worst of all - I don't have any preview. If I had a Matisse option for this kind of things (gradients, animations, other effects), I would be able to waste less time and have a better user interface.

Now, you guess that: Adobe programmers have development tools with a lot of graphic options! I never used Xcode by Apple, but looking at a handful of screenshots I guess there are graphics tools as well.

So, not only Emacs/Vi doesn't look good in this scenario, but even Matisse is not enough, being just the first step in the right direction. I expect/hope to see more graphic-oriented tools in the (near?) future.

Technorati Tags: , , , ,