December 29th, 2008

Java desktop spotlight – interview with Elie El Khoury of Woopra

Woopra desktop client is my favorite Swing application of the year, and it’s time to meet its creator – Elie El Khoury, as the Java desktop spotlight that has started with Don DeCoteau and Sam Berlin continues.

Tell us a little bit about yourself.

Elie Khoury - Photo by Sara SfeirMy name is Elie El Khoury, 23 years old. I live in the ancient city Byblos of Lebanon. Programming has been my hobby for more than 10 years. I was introduced to Java 5 years ago at the Lebanese American University which was the first university in Lebanon to teach Java as a main language.

I love Graphical User Interfaces and Graphic Design, that’s why I switched to Mac. I run a personal blog at that I maintain in my free time.

Besides computing, I’m a guitarist. I taught Blues Guitar and Jazz Theory and was part of a couple of bands.

What is your “elevator pitch” for Woopra?

woopra1Woopra is a web tracking and analytics service for bloggers and online businesses. It’s a Swing based desktop application that shows you what’s happening on your website in real time. Unlike other analytics services, you don’t need to refresh pages to get updates, you see instant statistics on a TV like interface.

What’s even cooler about Woopra is the Instant Notifications. A website owner can setup as many notification filters as they want and get notified as they occur. There are infinite filters combinations you can setup for all kinds of actions that might occur on your website!

Fore more information about Woopra, visit our a little bit outdated features page on the Woopra website.

In the age where browser-hosted solutions are mature enough to provide rich user experience, why did you decide to use Swing for the main Woopra client?

It’s true that the browsers today can handle very rich applications, but we cannot forget that the limitations are still endless and the browsers were never meant to handle heavy weight client applications like Woopra.

Before starting the development of Woopra, it was a very tough decision to take. The only advantage for having a web based application is the accessibility. You don’t need to download the Woopra application as you go, but our clients are the kind of people who carry their laptops (they are webmasters), so I would sacrifice accessibility for the different advantages provided by a desktop application (Desktop notifications, sockets, cross-domain connections, load on startup, sit in systray, reliability, speed, more interaction etc…).

I believe the browser is not yet ready to handle apps like Woopra. We all know how much time it takes to create an application that looks the same on IE6 and Firefox, is it worth it? But if I was to work on a Facebook like platform, I’d definitely go for a browser based solution because users would need to access it on public computers.

To add something, check out Twitter! Everyone is using a desktop application to tweet, this is another proof that people enjoy the desktop based experience much more.

As for why Swing not .Net for example? My simple answer is that I adore Swing and Java in general, and of course, the need to create a cross platform application.

Why do we not see more Swing-based user facing applications?

woopra2I believe it’s because the unattractive look and feel provided by Sun. Performance is no longer an issue with today’s hardware, but people want to see good-looking things. Adobe Air has done it correctly. You cannot make an ugly application with Adobe Air because they provide you with amazing UI Kits. With Java, it’s very easy to come up with a very ugly application, but what they don’t know is how much Swing is customizable.

Sun should consider working on the “Look and feel” aspect more in Swing. JavaFX is one solution but not the ultimate for Swing lovers.

What are Swing’s weak points?

Swing’s weak points are not many. But I would say that AWT is better in terms of native dialogs. I prefer the FileChooser instead of the JFileChooser because AWT’s is native. Also, the Anti Aliasing is really weak in Java. It looks different from a platform to another. Adobe Air has done it better!

Not to forget the look and feel, that is the major weakness of Swing.

What functionality is missing from core Swing, and would you want to see third-party libraries folded into the core distribution?

The JWebPane of course as mentioned by Sam Berlin of LimeWire. I’m glad they are working on it and have chosen the WebKit renderer. But I don’t believe we will be able to use it before a year of its release unless they provide it as a standalone API. People using PowerPC cannot even run Java 1.6 applications yet, we had to downgrade the application to work with Java 1.5 which is missing a lot of new interesting features like SysTray and more desktop tools.

What I’d like to see more with Swing is the window transparency for example, and the ability to create windows with custom shadows and rounded corners. ( I think that’s is now available with JavaFX).

Another interesting missing feature is the blinks in the task manager and the bounces in Mac OS X. There should be a simple function for the JFrame to do that.

One last missing feature in Swing and DesktopTools is the ability to change the screen insets. I would love to create an always on top floating window on the right just like Windows Vista’s Sidebar. I can imagine Woopra on the sidebar and always on top, showing live stats without intruding on other application (This is doable at the moment but we cannot change the screen insets). That would be awesome.

Woopra client has great responsiveness and excellent non-intrusive animations. How easy was it to code this functionality in Swing?

Almost 99% of the components you see in Woopra extend JComponent. I spend most of my time painting components. I spend sometimes hours testing colors, gradients on a simple simple button. Graphics2D is an amazing class that allows you to create whatever you need for your application. I didn’t really rely on the Swing components, I created my own layouts, buttons. You can easily notice that all the components are selfmade.

Do you have any plans to extract the Woopra skinning layer to a standalone look-and-feel library?

No, since I’m extending swing not skinning it.

Woopra client looks like a perfect candidate to be ported to JavaFX, the new direction of client Java. What are your thoughts on this topic?

I haven’t explored JavaFX a lot yet but I think it’s too late now to switch to JavaFX. I’d rather have more control over the animation and drawing. Swing is really huge and I’m learning more and more everyday about that package. I’m afraid Sun would consider JavaFX as Swing 2 and stop their core swing development. JavaFX and Swing should be parallel projects.

Anything else that you would like to add?

woopra3I’d be happy to develop Look and Feels for Swing, but I wish there are enough documentation on the web to do so.

Woopra 1.3 is close to be released which is more interactive, attractive, fast and optimized.

I want to thank you for interviewing me and I want to salute the other people behind Woopra today: Jad Younan, John Pozadzides, Vi Kim Vu, Lorelle VanFossen and Chris Patton.

December 29th, 2008

Swing links of the week: December 28, 2008

Here are some Swing links that you might have missed during the last week:

  • The discontent about timely and transparent disclosure of long-term plans for Swing is growing, and this week Geertjan Wielenga vents his frustration about the uncertain future of Swing in light of the Sun’s push for JavaFX as the apparent future of Java on desktop.
  • Andres Almiray has been hard at work with the Groovy builders for various third-party Swing components. He released version 2.1 of jideBuilder, has started work on the MacWidgetsBuilder, and showcases a few screenshots of the SwingPad 0.2.
  • Alex Ruiz kicks off a new series about testing JavaFX UIs by extending his FEST Swing library.
  • Jean Francois Poilpret is wondering whether it’s time to fork the SwingLayout project and start fixing its bugs. I can only speak for my own open-source projects (Substance and Flamingo), but i have found a surprisingly insignificant resistance to Java 6 as the minimum runtime requirement. This may be due to a relatively low usage of these two libraries, or this may be due to greater flexibility of runtime environments on the client side Java.
  • And finally, Yves Zoundi has announced two new releases of his projects. XPontus XML editor has reached release, and VFSJFileChooser remote file chooser component has reached release 0.0.4.
December 25th, 2008

Java desktop wishlist for 2009

The original “Java desktop wishlist for 2008” was posted a little more than a year ago, and today i am reposting it in its entirety. You can see the reasons why at the end.

While the Java blogosphere is raging with debates on closures, properties and other negligible language-level features, the client-side battle is still fought between Microsoft, Adobe and Apple. And while finally Sun decided to step in with JavaFX and improved applet handling, this will change little without the tools for content handling.

As i already said, the customers don’t care about the technology. In “The Agnostic Geek“, Brandon Carson writes:

when you look at a web page, do you think, “Gee, I wonder if they coded this in BBEdit or Dreamweaver?” I don’t know about you, but I don’t give a flip what software product is used to create a web page. Use TextEdit for all I care.

And so, who cares that the applets will load instantly when there are so few good applets? Just look at the amazing breadth of Flash content created by professional designers. Content that has rich multimedia capabilities. Capabilities that come built in with the platform. Platform that is oriented towards content.

So, what are my top two wishes for Java desktop for 2008?

Number one: Cross-platform support for H.264 and FLV formats.

Showing is good, but it also must support creating the content and editing the content (just look at the Sliverlight demoes). And don’t tell me that 99.9% of the market doesn’t need editing. If you want to lead the market, you have to cover everything that the competition has and then some.

I don’t know about the licensing issues, but the reference implementation for H.264 is not that big. And Onavia already has pure-Java player. So it can’t be that hard once you decide to put as many resources on that as you do on JavaFX. And even better, accelerate it with OpenGL and Direct3D, while at the same time gracefully degrading to software loops on older cards.

Number two: Converters and viewers for competing markup formats.

You know what i’m talking about – those pesky competitors that have 99.9% percent of the consumer-facing rich desktop market. Flash / SWF, Flex / MXML and WPF / XAML. Each has its own set of designer tools for creating rich content. Each has armies of professional designers versatile in using those tools, in addition to Photoshop, Maya and others. Do you really expect them to master yet another (unproven) designer tool?

If JavaFX wants to have a fighting chance, it needs to provide a simple migration path. A path that allows taking an existing Flex / Silverlight application and importing it to JavaFX (at least the visuals). XAML has at least three – converter from Maya, converter from Photoshop and converter from SWF. The importing is not enough. You have to have exporting as well. If you’re not convinced, read what Joel Spolsky says about how Excel managed to overpower Lotus:

And this reminded me of Excel’s tipping point, which happened around the time of Excel 4.0. And the biggest reason was that Excel 4.0 was the first version of Excel that could write Lotus spreadsheets transparently.

Yep, you heard me. Write. Not read. It turns out that what was stopping people from switching to Excel was that everybody else they worked with was still using Lotus 123. They didn’t want a product that would create spreadsheets that nobody else could read: a classic Chicken and Egg problem. When you’re the lone Excel fan in a company where everyone else is using 123, even if you love Excel, you can’t switch until you can participate in the 123 ecology.

If you want to have professional designers to switch to JavaFX, provide a clear path back. Not that they’ll take it (of course, if the tools and the runtime are bad, they will), but it will give them a nice sense of security.

An extra step would be to allow using the same exact content at runtime without converting it to JavaFX. Soyatec does it partially for XAML, so it can be done. But if you do it, support the complete feature set (including 3D and, guess what, rich multimedia). A bonus part would be to include a bitmap to SVG converter – see VectorMagic for inspiration.

That’s it. I have only two wishes. Granted, these are two big hefty wishes. Will they come true? The first one might partially be, and the second one is highly unlikely.

So, why the repost? The reasons are quite simple – these two wishes have not been addressed in 2008.

December 21st, 2008

Swing links of the week: December 21, 2008

Here are some Swing links that you might have missed during the last week:

Finally, Mikael Grev has announced release 3.6.2 of MigLayout manager for Swing and SWT. Mikael has been vigorously pushing for inclusion of this project in the core JDK distribution, amassing an impressive number of 289 votes in the bug parade. I am not quite convinced that it will be a good match. Looking at the available release notes history (since June 08), i see quite a few bugs being fixed (even this very announcement was made on version 3.6.1, with a bug creeping in requiring another minor release), as well as improving support for IDE integration. This is a perfectly normal situation for any project, even when the APIs are frozen as far as the project developers are concerned. Would you want to forego quick bug fixing cycle for a larger audience? Would you want to risk the restrictions of JDK (never breaking the APIs) even you are positively sure right now that this is the final state? These and other related questions don’t have a definitive answer (to witness quite a few API disasters in the core JDK), and tomorrow’s interview (not related to MigLayout) will provide an interesting take.