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.

My 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 http://www.ekhoury.com 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?

Woopra 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?

I 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?

I’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.

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 1.0.0.2, and VFSJFileChooser remote file chooser component has reached release 0.0.4.

If you’re following my Twitter stream, you know that over the last few days i have been working to bring the Office Blue skin of Substance look-and-feel closer to the original visuals. The original visuals for Office 2007 built-in skins are comprised of hundreds of hand-crafted images and around 1500 colors, and are quite a challenge to reproduce even with the rich skinning APIs of Substance.

Here is a screenshot of the old Office Blue skin:

While the overall direction is right (washed blues + a combination of yellow / orange colors for active states), it was quite off in both hue and saturation.

Here is how it looks in the latest 5.1dev drop of Substance (code-named Panama):

Office Blue skin is by far the most complicated Substance skin, and uncovered deficiencies in the core library as far as the skinning flexibility goes. The most visible change is breaking the API of highlight painters to add two new parameters (for passing the border color schemes). All the other changes are additive, bringing more control over the definition of color scheme bundles.

You can now associate the following three new types of color schemes with each component state (see the SubstanceColorSchemeBundle and OfficeBlue2007Skin for more details):

• Color schemes for marks (check marks, arrow icons, …)
• Color schemes for tabs (see the white fill of the selected tab)
• Border color schemes for tabs (run the WebStart demo below and move the mouse over the selected tab to see the orange glow)

At the present moment, the Office Blue skin is defined by fifteen different color schemes that cover thirty six different component state configurations. Additional color schemes may be added later to further tweak the visuals.

As with Substance 5.0, performance is the major factor. Adding the new color scheme kinds and component state combinations introduces about 0.8% performance degradation to the skins that do not use them, and about 2.1% to the skins that do. I do believe that the new fine tuned control over defining the visual aspects of your custom skins is worth it, and i will try to bring the numbers down until the final 5.1 release (set to coincide with the final 4.0 release of Flamingo).

The final piece is a new visual tool to assist in defining Substance color schemes based on the existing designs. It is called Jitterbug and will be properly introduced next week. You can create a new color scheme with Jitterbug in under a minute, and all fifteen color schemes of the new Office Blue skin were created with it.

To see the new Office Blue skin in action on the Flamingo ribbon component, run the following WebStart demo:

If you want to test new visuals and APIs, you will need to take the latest 5.1dev drop of Substance (code-named Panama).

Yesterday’s entry has marked the completion of all planned core features for the version 4.0 of Flamingo component suite (code named Fainnear). Here is a short list of all the features that have been added to Flamingo ribbon component – click on each feature to see the screenshots and the relevant APIs.

• Contextual task groups
• Taskbar
• Application title bar
• Main application menu button
• Pluggable resizing policies
• Minimizing the ribbon
• Horizontal scrolling for content under small widths
• Better support for placing core controls and button groups in ribbon bands
• Key tips
• Screen tips (AKA rich tooltips)

The ribbon component is ready for application testing and feedback. Release candidate is scheduled for January 26 and the final release is scheduled for February 9.

To see the Flamingo ribbon component in action under core look-and-feels, run the following WebStart demo:

To see the Flamingo ribbon component in action under Substance look-and-feel, run the following WebStart demo:

If you want to test the ribbon in your applications, you would need the following (the last two only for applications running under Substance look-and-feel):

• The latest 4.0dev drop of Flamingo (code-named Fainnear)
• The latest 5.1dev drop of Substance (code-named Panama)
• The latest 5.1dev drop of Substance Flamingo plugin