Ben Galbraith's Blog

April 2006 Archives

A Desktop Application Developer's Conference?

(cross-posted on Married... with children)

I've already talked about the Ajax conference that we over at Ajaxian.com are producing (May 10-12 in San Francisco; won't you join us?). As I contemplate the great fun that we'll have at that event, I've started thinking of my other love: desktop application development.

I spend the vast majority of my time developing Swing applications. I am more interested in desktop app development than pretty much any other programming discipline. As I work with other desktop application developers, I'm seeing a lot of gaps in our collective knowledge. Too many of us really don't understand good UI design principles. Often, we haven't taken the time to check out what our (WinForms, Cocoa, SWT, etc.) neighbors are up to. And, of course, wouldn't it be nice to learn more from others about how to use our toolkit of choice more effectively?

Do you think it would be a good idea to hold a 1-2 day Desktop Application Development conference? I'm thinking such an event should have at least a 50% focus on user interface design issues (i.e., interaction design) with the other bit being about how to get the bits to actually do the interaction. I'm also wondering if it wouldn't be a good idea to invite all desktop application development disciplines to speak and attend. I for one would be fascinated to hear talks from various foreign GUI toolkits about how their stuff works and what they're up to.

Should it be a small, boutique, no-frills conference focused on intermediate/experts, or a larger, more general-interesting conference with a lot of introductory-level material? Should it have a Java-only focus, or is inviting the entire community interesting to you?

What do y'all think? Would holding such an event in the fall or winter of this year / early next year be a good idea?

International "Focus Abuse Awareness" Month

(Cross-posted on Married... with Children)

I am so sick of badly behaved focus behavior! I hate it when websites have onload handlers that do janky things with the focus, moving it to some arbitrary form field, not realizing that many users start interacting before the page is completely loaded. I hate it when desktop applications steal the focus, causing whatever I've been typing in some other appication to be lost.

Please, please, can we just all work together for a world where the active window keeps focus until the user decides otherwise? Where websites are smart enough to change focus only if you're not currently interacting with the page, if they insist on changing focus at all?

Finally... Client Properties You Can Use

One of the Java Swing GUI toolkit's strong advantages is its flexible, easy-to-customize architecture. Swing isn't easy for beginners, but once you grok it, there are a lot of great ways to customize the behavior, state, and appearance of a widget. Indeed, if maximum flexibility is your goal, you'd be hard-pressed to find a better toolkit on any platform.

I used to hand-code all of my Swing code, including UI layouts. Thankfully, over the past year or two, several high-quality graphical UI layout tools have emerged, the first of which (that I noticed) was JFormDesigner -- which I still use. But there's one feature I really miss from the current generation: client property support.

I find myself constantly using client properties to extend the functionality of Swing components. For example, I'm a big fan of externalized formatting for Swing components, like what Guy Romain is doing with the Fuse project. While Fuse is annotation based, I'm a simpler guy -- I want to be able to define properties of Swing components in an external file (very much like a CSS file) and then apply those styles to Swing components by id (which I map to the JComponent's name property) and by "class". So, I can do something like:

JTextField.productCode {
    columns = 10;
    fontSize = 10pt;
    font-family = Helvetica,Arial,Dialog;
    border: 1dlu solid black;
}

and map that to all JTextField's with the "productCode" class. Ah, so how do I assign the productCode class to a component? Subclassing is of course a bad idea. I maintain that you should never, ever subclass Swing components to add general functionality to them (if you ever hope to leverage a single third-party component).

The answer, of course, is a client property. I can define a client property key "org.galbraiths.clarity.styleClass" and set the value to "productCode", and I've now got this great system for allowing all JComponent's to specify a class for styling. (I actually apply the styles via a decoration mechanism that applies to all component hierarchies before they are displayed, but that's another story.)

Alas, the current versions of JFormDesigner, NetBeans, and IDEA don't provide any support for setting client properties. Ugh. So I have to write some kind of custom code all over the place to do this, which I'm loathe to do. I suppose I could, but, frankly, it makes my WinForms developer friends laugh at me, and I hate that.

Fortunately, that's about to change. The next version of JFormDesigner introduces support for client properties. You go into the Preferences menu and define your standard client property keys, like so:

and then the property pallette lets you set those values:

Nice! I'm one step closer to my dream development environment for my Swing framework. The next version of IDEA's GUI builder will also support client properties; hopefully, NetBeans will too.

By the way, I'll be talking more about this, and will be sharing some of my code under a license anyone can use, at this year's JavaOne in my Swing session. If I've said something you particularly disagree with, make a rude comment to this blog, by all means, but even better -- come and heckle! Chet can't be the only one with rabble-rousers in the audience.

This work is licensed under a Creative Commons License.