Decent swing code
Most people these days (at least the vocal ones) do web/server side stuff. They’ll pontificate at great length about having wonderful designs, MVC, action class, IoC, command frameworks, and all that twaddle. They’ll feel clever for cracking what is, at its core, not that complicated of a problem.
The one thing however that seems to be sorely lacking is an equivelant in the swing world. For anyone who has done any serious swing work, you probably know that it’s a LOT more difficult than silly web crap. With web stuff, you have some constraints which greatly limit what you can do and how (request/response, page views, etc). That in turn makes life much easier; there’s only so many ways of doing something.
In the swing world though, things are radically different. There are a million ways of doing the same thing. It’s HARD. Worst of all, there are no howto’s that will talk you through writing large scale swing apps. For some odd reason, it’s a secret art with very little concrete info out in the wild.
Sure, there are a few million component libraries out there. Those still don’t address the need though. The only attempt at it seems to be in the jgoodies products, which are a good start but still have some annoying flaws (usage of statics, adding a new action involves touching many files, etc).
For example, what’s a good way of managing Actions? Do you have an ActionFactory? Do you follow them religiously, or fall into the odd anon. inner class? How much should your actions know about your UI? Do you tie them to the controller or view? Should they update the model or the view?
The problem is made a lot worse by the fact that any idiot can knock up a swing interface that seems functional. It’s laughably easy to slap on some panels, a few tables, and a bunch of buttons that Do Stuff. So Swing ends up getting a bad rep because it’s very accessible for the dummies, but very hard to actually get just right. There just doesn’t seem to be any easily available frameworks to provide guidelines for all this stuff.
Of course, it’s nothing compared to the massive retardation of shite like SWT. But then, in that case their cause is so hopeless it’s not even worth highlighting the problems. SWT is a boil that needs to be lanced as soon as possible before serious infection occurs.
December 4th, 2003 at 12:36 pm
hmmm, sounds like you’re after SWT’s JFace =)
December 4th, 2003 at 1:20 pm
If you can find the documentation? It looks like both Hani and I are looking for in depth articles, MANY of them, about how to use this stuff the “correct” way, not just the easy way.
December 4th, 2003 at 1:20 pm
If you’re building some Swing stuff and looking for a command/action framework, try out XWork for it… I’ll help however I can, because I’d like to see someone using it outside the web world, and that’s all I do at work…
December 4th, 2003 at 1:27 pm
GUIs aren’t that hard.
No harder, per function point, than web based systems.
Try something like the “humble dialog” proto-pattern: https://www.objectmentor.com/resources/articles/TheHumbleDialogBox.pdf
December 4th, 2003 at 1:37 pm
Why hurl insult on SWT without presenting any valid argument about it.
December 4th, 2003 at 1:52 pm
Ah, I love this topic. Problem with Swing is there is NO “container” like framework that standardizes on a consistent way of creating windows, layout of such, etc. Eclipse’s IDE is about as close as I have seen in creating a somewhat easy to expand upon UI application framework. With their 3.0 work allowing the use of the Rich Client Project as a “headless” plugin engine/UI framework, it will be easy to develop SWT based applications.
But here is my big issue with this. SWT!! SWT is a great thing… it brings about something Swing should have done, toss out the “underlying” AWT needs and create a powerful, flexible and fast UI for Java. HOWEVER, as many of us probably know, Swing does some things better, some things worse. What I would personally like to see the SWT JNI stuff brought into Swing, or at least see Swing’s JNI updated to be as fast as SWT. There are some areas, like JTables and JTrees that from what I have read (sorry, no personal experience with SWT) are better than SWT.
Now, wouldn’t it be great if there was a similar Rich Client framework that used Swing directly, still supported plugins, etc? I am not talking about the use of the SwingSWT plugin thingy that requires both SWT and Swing to work. I mean, a completely pluggable framework that is built around Swing instead of SWT?
Enter Theseus Pluggable UI Framework. It is a work in progress, but it is something I have been working on for over a year (at least the plugin engine). Before the RCP of Eclipse was announced a few months back, probably about 8 months ago, we started working on a “simple” UI framework built around our plugin engine. Our plugin engine works in a similar manner to Eclipse, in that it supports extension points and extensions to those points. Unlike Eclipse, the engine automatically resolves all dependencies for you at runtime. It will soon support unload/reload of plugins, and unlike any other plugin engine on the market (at least that we have found), our engine supports a single plugin archive file format (basically a zip file) where you package up your plugin classes, any libraries it depends on, images, resources, etc, into a single file. You can give this file any extension you want. At runtime, you just drop the file into one of any directories the engine is configured to look for plugins in (or at a URL location such as a web site), and the engine will use the file as is, uncompressing and finding classes on the fly.
The UI framework we are creating is also similar to Eclipse, in that we are creating various extension points that plugins can extend for certain functionality. We are “hoping” to mimic the idea of views, editors, perspectives and such. Already working is the ability for all plugins to define menu items and toolbar buttons via the plugin.xml config file, and the UI is created without a single line of plugin code ever being created. All plugins are lazily created, like Eclipse, as needed at runtime. Optionally they can be auto-started when first loaded, such as the core UI plugin has done. We will be providing various extras like a new custom file chooser component (not JFileChooser) that is far more customizable than JFileChooser, a built in JavaHelp and possibly HTML help facility, user preferences that load/save, a Preference dialog that plugins can add preference pages to, a Wizard component that any plugin can use to construct wizards, possibly a few “services” like email and ftp capabilities so that plugins can simply extend a point and access email to send/receive, etc, and some other things. The UI will be customizable, but the current idea is a menu bar, status bar, left side outlook style task bar, and right side “work space” area, with a toolbar that can possibly be dragged on/off below the menu bar. Also, two things I really like about Eclipse, the perspective idea which in my mind is just a button that can “bring up” a set of windows in a specific position defined by a user, and the idea of dragging different windows into each other so that a tabble single window can be used to switch between windows.
Anyway, the goal here is to make a powerful Swing based (and SWT could even be used if someone wants to add swt.jar to an optionally replacable “core” plugin) UI framework that can provide a very easy to extend pluggable approach to GUI development. Like the aim of the Eclipse RCP, this project aims to provide a much faster and more consistent and stable manner in which to create a Java GUI application.
Please feel free to check out our progress at
http://genpluginengine.sourceforge.net/
and
http://sourceforge.net/projects/genpluginengine
The initial pages are for the genpluginengine (now named Theseus Plugin Engine), but the CVS repository has the various bits of source for the codenamed appshell framework.
Just keep in mind, its a work in progress and the UI framework will be quite a ways off. The engine is still being worked on, adding a simple services model to it now.
Look forward to any replies, feedback, or perhaps joining the project and helping out.
December 4th, 2003 at 2:36 pm
Hooray - finally someone who isn’t in love with SWT. I’ve never understand the fawning over SWT that I see, especially from people who have never coded a GUI before. Apparently one semi-usable SWT application (eclipse) is all you need to win the hearts and souls of the Java community.
December 4th, 2003 at 3:25 pm
The love with SWT, for the most part, is because Swing usually looks like shite. And it doesn’t have to.
December 4th, 2003 at 3:51 pm
Right on, Hani.
I think that only when you have tasted both can you give your opinion. And to all of you wanting the side by side comparison - it’s a dumb idea. You can write a typical application using both tookits. Opinions are based hoewever on more subtle things like gut feeling, creativity and others that do not get put into words very easily. So, I would never even touch SWT again. It smells. It’s simply a matter of taste, and like the saying goes “You either have the taste or you don’t !”
December 4th, 2003 at 4:17 pm
This is funny. So in java land it is hard to write gui? I thought any high school kid could write decent GUI in VB3.0 back in 94.
So for all this years java can’t come up with anything usable. And this is technology which suppose be run on consumer electronics devices and bring interactivity for the dumb VCR’s.
December 4th, 2003 at 5:29 pm
> I thought any high school kid could write
> decent GUI in VB3.0 back in 94.
No, they could write what people THOUGHT was a decent GUI back in 94. In fact, it is hard to write a decent GUI in most languages. The exception is VB, which makes it impossible.
AB
December 4th, 2003 at 5:52 pm
What the hell is “large scale swing app”? Good rant though !
December 4th, 2003 at 10:25 pm
You smoking crack. Neither is any where near the realm of hard.
December 5th, 2003 at 2:32 am
I cannot believe that these web junkies actually believe that anyone would use their ‘generic command framework’ in a Swing application - please keep your crap for retarded MVC/2 web applications.
‘The ActionContext is acquired through the static ActionContext.getContext() method.’ - this is really impressive!
December 5th, 2003 at 4:18 am
Right on Hani.
Any half-brained muppet, high-school kid or Indian
contractor can slap a few buttons and text fields
in a JPanel and call it GUI. Building commercial
quality applications is *not* straightforward - it’s a lost art. Swing as it stands is little more than a collection of widgets - look at any app written by an inexperienced Swing-er and it’s littered with anonymous ActionListeners, ResourceBundles, UI locked up by processing on the event-dispatch thread, poor or no use of GridBagLayout, and hundreds of modal dialogs.
There’s a lot to more writing UI than how it looks - it takes time and experience to understand the subtler nuances of how the user interacts with the UI. Unfortunately, few people will notice good UI as it doesn’t interfere with their workflow and lets them get on, whereas most people will notice bad UI, usually because it’s screaming in their face “PAY ATTENTION TO ME!!!”.
And it’s usually called “Windows”…
December 5th, 2003 at 8:36 am
Not having done many GUIs (professionally, I’ve been firmly in the “retarded web apps” camp :), I’ve always heard JBuilder had servicable GUI-building tools…I haven’t used it since ~v4…does anyone have an opinion for the GUI code it creates? How about Sun’s “project rave” or whatever it’s called now…isn’t one of its goals to ease GUI development? Cheers, all…
December 5th, 2003 at 11:13 am
The “Definitive guide to Netbeans” has quite a few ‘large scale’ Swing hints (Drafts are available at URL below).. also, to Kevin Duffey, Netbeans provides has been an application framework for Swing apps since before Eclipse existed as Eclipse.
December 5th, 2003 at 11:31 am
Rik,
I suppose only muppets, high school kids and Indian contractors (the current whipping boys for unemployed or bitter IT workers) build crappy GUI’s. I guess non-Indian contractors or Indian non-contractors are capable of building decent GUIs.
Of course, it follows that the worst GUI code is produced by muppets enrolled at the Bombay High School For Future Contractors.
December 5th, 2003 at 12:17 pm
The “Definitive guide to Netbeans” has quite a few ‘large scale’ Swing hints (Drafts are available at URL below).. also, to Kevin Duffey, Netbeans provides has been an application framework for Swing apps since before Eclipse existed as Eclipse.
December 5th, 2003 at 12:33 pm
Yes, this is true about netbeans. However, it is bulky like Eclipse, much slower than Eclipse, and frankly, after trying to aclamate myself to several versions, giving up after each one, I wouldn’t care to build my professional gui application upon, in my opinion, failed IDE. Project Rave looks to ratify that situation, but its a long time coming, long overdue. Also, the “core” is my plugin engine, which at 50K or so with embeded xml parser, can be used for any type of application, not just GUI. You can add it to an existing application to provide the benefits of a pluggable architecture so that a possibly difficult to extend application can easily add extensibility through the plugin engine.
I think the point, for me, is that at least at the time there was no great pluggable UI framework that provided the capabilities that Eclipse does in the manner it does, and yet I still consider it more difficult than need be. Whether or not anyone ever uses my framework is of no concern to me. I will use it to build some apps, I hope to see it be useful for many other developers. If not, no loss, that is why it is free to use. Perhaps developers can pick apart pieces of my project for their own use, perhaps a blogger will reply with how insane I am for thinking anyone would ever consider using my framework. I like to create, and I like to try to help other developers, so this is one of my offerings, and basically I wanted to make it known to other developers that the Eclipse/SWT team will not be the only game in town, that my framework is similar to what Eclipse will offer, on a smaller scale, but perhaps on an easier scale as well.
December 5th, 2003 at 4:20 pm
Back in the day (mid 90’s) I used to write commercial windows applications using MFC for Autodesk. I actually got pretty decent at. I wrote a wrapper around MFC and created a C++ command/response framework to handle the user interaction with the GUI. Then came along the web. Everyone had to have a web-based application. So I just adapted my C++ command framework I developed for GUIs and adapted it for the web by creating a new java-based framework for building websites. After 3 years of building the framework I launched playfantasy.com.
At one point I starting fooling around with Swing but the apps looked so bad that I decided it was not worth the effort. So what do I want to do now? Well, I’m tired of building websites because it ends up being the same thing over and over again and the challenge is no longer there. I’d like to get back to developing GUIs. I really miss my C++ days w/ multiple inheritence so I’m looking into using C++ using vxWindows.
December 6th, 2003 at 2:08 am
The question about Actions is vastly preferable to the lack of questions about Actions — it took me months before I realized virtually all the Swing work I’d done was crap because I hadn’t centralized my code around actions and events… but then, I’d never written a Swing app before.
I think a large part of how you do this right is to screw up the first time. Nothing’s going to save you if you have no experience and no mentors — a tutorial will take you up to a certain point and then drop you off in the middle of nowhere.
You haven’t even touched on the horrors of heavily modifying JTree models or the rigors of error handling in distributed applications. It’s just a mess, and worse, it’s a mess with many sub-optimal solutions.
I agree that there need to be better design patterns for UIs, but this goes back to “other experience.” It’s not that people don’t know it, but there are very few people with the time, skill and patience required to teach it.
December 6th, 2003 at 3:31 am
Mmm… in my opinion and in my not-so-good experience the problem with Swing is that
a) it is a difficult, counter-intuitive api.
b) Java programmers are usually asked to do “more important stuff” (like boring sql connections et all).
c) usually “Usability” and “Design Guidelines” are sacrificed to other gods like “Finish it for yesterday” and “The important thing is that it should work”.
Point C is common to all the other worlds. You have decent interfaces only when you have a project large enough to accomodate as well some experts on usability.
December 6th, 2003 at 3:33 am
Swing is fat and overengineered. Try modifying the JTable to support decent column sorting, for instance. I had to go out of my way to make table behave the way I wanted it to. (See the URL for my app, it’s WebStartable.)
The main problems with Swing are its ridiculous memory usage and the long startup time. Until VM sharing becomes a reality (on Windows), this will remain a sticking point for the adoption of Java applications on the desktop. (Last time I checked, VM sharing wasn’t going to be implemented in JDK 1.5.)
As for SWT, I don’t think it’s “shite”. Just because Swing makes it easy to slap together a GUI with a few lines of code doesn’t mean it leads to better applications. In fact, you ought to spend much more time designing and tweaking your GUI than working with the actual API, so the relative difficulty of one API over another becomes a moot point.
A native GUI still makes a better impression on the user. No matter how much you fine-tune them, Swing apps still feel strangely out-of-place. This is not necessarily bad, it’s just that the user always feels more comfortable when a GUI behaves the way they are accustomed to. If an interface breaks established conventions - like Metal does so blatantly - users get annoyed. Granted, the JGoodies L&Fs address nearly all of Metal’s weaknesses, but the responsiveness still isn’t completely “right”.
In fact, while writing this comment, it strikes me that a GUI is not something you would even want to make cross-platform. (I know this is an obvious point, but it took me a while to get there.) The differences between platforms are just too great, while at the same time it’s important to make the user feel as comfortable as possible. In other words: native GUIs are the answer and you just have to accept that you might have to do some double work. The end result is all that matters. (This is all very idealistic, of course, to the point of being somewhat naive, I know.)
December 6th, 2003 at 3:15 pm
Whatever happened to: First post!
December 7th, 2003 at 1:16 am
I guess you can still get a ‘last post!’? :)
December 7th, 2003 at 8:10 am
No, you can’t.
December 8th, 2003 at 10:10 am
Finally something we actually agree on, Hani! I wouldn’t not saying that web stuff is easy, but Swing stuff is *really* hard.
I’ve written a bunch of fat-client/desktop apps in my life and I’ve never gotten one single one *completely* right. I’ve written millions of web-apps and a bunch of them came out just perfect.
One interesting thing I’ve been looking at is using a messaging based approach instead of the standard command/action/procedures-as-objects stuff. Have a look at http://www.werx.org/
Haven’t used it, but might be cool.
December 8th, 2003 at 1:10 pm
I’m using werx currently for my foray into fat clients (link on my weblog), and loving it. It is very easy to use and doesn’t impose on your objects. Very smart use of reflection.
December 8th, 2003 at 9:28 pm
came a bit late to this one, but from my POV Swing isn’t that hard, and while it is [just a tad] overengineered in places, it is a very well designed MVC framework. My biggest beef with it is not so much it itself, but Java that limits its utility. What I want to do is to supply a Model class that contains properties (getters and setters, public members, whatever) and a view class that defines the layout of the panels and entry fields that act upon my model. Then I want to say, this field binds to propertyX, this one to propertyY, and from then on, whenever my model is updated, propertyChangeEvents propogate those updates to the model, and if my view is updated by the user, DocumentEvents (or equiv.) are propagated to my model. In Java, the lack of function pointers means I need to supply String names to my binders and I lose the ability to formally typesafe my UI (and don’t get me started on unit-testing UIs).
Fortunately there is a technology that is ideally suited to GUIs and MVC design in particular, AOP. As propertyChangeEvent production is a crosscutting concern of a model object’s mutators, so decorate your model object mutators to produce them. Binding specific model properties to a view is orthogonal to either the model, view or even the controller classes, so bind them with an aspect. Much easier and cleaner.
Anyway, I recently had to do a Swing app again after quite some time doing webby apps, and even without my aspect MVC binding framework it was pretty easy and fun in comparison!
December 13th, 2003 at 6:23 am
Hani,
Great points you’ve encountered :-)
I’ve done massive Swing programming for years before going to web and can understand each of the points you’ve listed.
I’ve always loved Swing as one of the best GUI toolkits out there. Really flexible and flawless MVC architecture makes it a masterpeice from architechtural point of view. And as for the performance issues people are usually refering to, I should say that by having it more and more optimized on each version of JDK and by having more powerful PCs released each day, it’s going to be one of the minor issues. No need to mention the way of programming too! Not so optimized algorithms can easily kill the performance while programming a bit more wisely can bring a GUI to us which does not differ much from a native one.
You can also easily hang yourself with enough rope provided there! So you should just use the API you have with some caution… Especially the newbies who are usually lost among the layers and APIs. This is the point when people usually start shouting and complaining about Swing!!
Cheers,
Armond
December 16th, 2003 at 4:47 pm
Reasons against SWT? Here’s a start.
1. You have to deallocate practically everything you allocate. Afterall, this is Java, and there’s not anything like garbage collection.
2. The Eclipse project hyped and hyped SWT to look “more like the native interface”, and yet running on any styleable version of Windows it completely fails to do that. Maybe I would buy their claim if they had Qt support out of the box, because at least Qt knows how to look like the OS it’s running on.
3. Eclipse is built out of it. And before you Eclipse zealots beat me to shit for saying that this is an issue, look at how much faster IDEA is. I’m not saying this is SWT’s fault, but it certainly leaves a bad taste in your mouth.
December 19th, 2003 at 10:44 am
Totally agree with Hani on this one. I am also on of the guys, who cant afford to only accept web based projects, so i have to do Swing and i still feel like the last punk when doing it. Of course everything works, but there is some feeling that it could be much better. A feeling that i dont have too often with web based stuff.
Fortunately i am jgoodies customer and karstens framework is quite nice. Apart from his extremely good looking theme and components, he is also a skilled GUI programmer, allways kind to answer one or two questions regarding swing frameworks.
I think he is one of the best Swing coders i ever met and his framework makes my swing coding a little bit better ;-)
February 2nd, 2005 at 2:11 pm
Also … check out sandraSF.com for good swing
.V