The Old Joel on Software Forum: Part 3 (of 5)

Cross Platform GUI Redux

OK, so which is it:

Java and SWT

or

C++ and wxWindows?

Both give you cross platform deployment, albeit differently. Both pretty much look like a native app for the respective OS when deployed

Has _anyone_ here done a careful analysis and comparison of which is the better way to go? Anyone cranked out a small test app using both and compared the effectiveness, responsiveness, and overall hassle factor?

The downtown office wants to know.

Mitch & Murray (from downtown)
Thursday, January 1, 2004

Don't forget QT!

Also, there is the CLX, used by the excellent Delphi / Kylix RAD tools pair (Kylix is Delphi for Linux).

CLX is based on QT, but it's higher level.

MX
Thursday, January 1, 2004

My opinion:

Java + SWT + GCJ: Great if you want to leverage your Java skills. Unfortunately SWT is pretty weak in the number of controls available. Also, the memory footprint is kind of huge. And I'm not terribly comfortable about the garbage collection actually working correctly in this solution.

wxWindows: Great solution, but the documentation is weak. You'll have to refer to the source code a lot.

Chip
Thursday, January 1, 2004

I've used apps written in both, and I can say for sure that I dislike apps written in Java. It's a pain to deploy because your users need to get a java runtime before they can run your app. I have not found it to look like a native app, and the responsiveness of the application sucks.

C++ and wxWindows looks and feels like a native app, at least on UNIX and Windows. I haven't found it to be any worse than MFC for development and documentation, probably because I don't have a huge MFC development background. The documentation definitely isn't as comprehensive as the Microsoft documentation. The examples included though are sophisticated enough to get me through, at least so far. I may feel differently about that later.

From the user's perspective it's also a lot easier to install a wxWindows app. The necessary libraries can be linked staticly, or if there is a distribution CD you can include the fat DLL. Distribution to UNIX users is a little more problematic, because wxWindows naturally builds to a dynamic library with some problematic dependencies. This is a general problem with UNIX GUI apps though, usually overcome by static linking for binary distributions.

Clay Dowling
Thursday, January 1, 2004

By the way, there's a wxPython project underway that wraps wxWindows for Python: http://www.wxpython.org/

I don't have experience with this wrapper but the demo app included in the download looks quite impressive. Almost all the Windows GUI functionality is there, and none of the sluggishness and ugliness of Java GUI apps.

Chris Nahr
Friday, January 2, 2004

If you are comfortable with C++ (or Python), use wxWindows.

Java is a great language for some things, but client-side applications with rich GUIs isn't one of them. Sure someone will pipe in with a counterexample, and it will almost certainly be either JBuilder or Eclipse... the same ones mentioned all the damn time as counterexamples because there are so *FEW* actual usable Java GUI applications, because writing them to be nearly as responsive as native apps is really friggin difficult, negating much of the rapid developement edge Java gives you to start out with. Not to mention all of the fun release engineering issues that result from having to ship a JVM, set local classpaths, etc, without stepping on any existing Java installations.

QT has too many licensing issues to bother with, if you ask me. If you don't release your source code as GPL you need to pay a rather high license fee to distribute your app, on the order of $3000 per developer if you want to hit the three major platforms (Win, Unix, MacOS). Granted, that isn't an obscene price if you're a big corp, but QT isn't $3000 (per developer) better than wxWindows, IMO.

Mister Fancypants
Friday, January 2, 2004

My personal favourite is FLTK [ http://fltk.org/ ] - it goes with C++ or Python, and works on Win32, Unix, Mac and various other embedded platforms. It's not as widget-complete as the other toolkits, but has a very respectable set, is easy to use, and is extremely fast.

Java guys should also be aware of SwingWT - it's a port of Swing to SWT, that lets you run Swing apps unmodified with an SWT (hence, native widget) backend. Coupled with GCJ, you get a toolchain that compiles a Swing app in Java into a native executable utilising native widgets; Haven't tried it myself (i don't do java lately), but screenshots look very impressive. See [ http://swingwt.sourceforge.net/ ] for more.

It really depends GUI for what. There's no ultimate solution for anything (even though there are solutions which are ultimately bad for almost everything).

Ori Berger
Friday, January 2, 2004

Someone has a wxPython IDE in development also: Boa Constructor. It's still in it's infancy at version 0.2.6 but it too looks impressive at first glance.

old_timer
Friday, January 2, 2004

The downtown office needs to provide more details on what it wants the app to do if it wants a meaningful answer. Are your programmers really equally comfortable with C++, Java, and Python? What kind of widgets will you be using? What kind of machines will you be deploying to? Is the app going to be large, thus making memory usage and speed an issue?

A small app probably isn't sufficient to determine what should be used. My advice is to collect the most difficult looking GUI features in your requirements. Then, head off to the documentation for each library and see how you'd go about implementing those features. I was able to easily eliminate SWT as a possibility for a project because it does not have powerful enough custom drawing capibilities to implement some of the projects widgets.

Matt
Friday, January 2, 2004

The wxWin API is a clone of MFC in many ways. In about 90% of the functions you can port simply by replacing the C at the front of the function name with a wx.

Here's an article explaining how to do it:

http://www-106.ibm.com/developerworks/linux/library/l-mfc/?open&l=920,t=gr

Chip
Friday, January 2, 2004

I believe that people need to do some more research to inform themselves about Java apps and their deployment with a JVM. It's incredibly easy to do without stomping on some version of Java already installed on the machine or worry about classpath issues. The approach we typically take is to embed a JRE directory (the one we certify our product against) within our product directory. We specifically reference that JRE (which is not "installed," it simply exists within a directory) when launching our application (using a LaunchAnywhere native executable as a wrapper).

With regards to client applications developed in Java, I suspect many Java naysayers have simply never seen a well developed Java application. Here's a screenshot of one of ours:

http://www.orchardsoftware.com/SCREENS/crs1_lrg.jpg

It's an interactive, multi-media application that was developed entirely in Java and runs on Mac OS 9, Mac OS X, and Windows. It also runs on Linux with the exception of the sound and voice recording features, which use the QuickTime for Java API.

Here's another of our Java applications, which runs on OS X and Windows (uses JDK 1.4, which rules Mac OS 9 out):

http://www.ea-software.com/images/screens/dr/mainidea-1b.gif

And one more, which works on Windows, Mac OS 9, and Mac OS X:

http://www.journeypassport.com/math-scr_d.shtml

Note that this one includes a skinning feature allowing the end-user to instantly change the look and feel to one of 12 different skins (examples shown).

It's very apparent that there are outdated and misinformed ideas about Java.

Michael Connick
Saturday, January 3, 2004

"With regards to client applications developed in Java, I suspect many Java naysayers have simply never seen a well developed Java application."

No, we haven't. Instead we've seen many a crappy-looking Java aplication. Which is precisely why we make such comments.

See, if you have to go looking and point out "here, I found a Java client app that actually doesn't suck!" you've already admitted our point. We don't need someone to pipe up and point out a C++ or .NET GUI app that looks and works well, because most of them do. It's a matter of course with most languages other than Java.

Chris Nahr
Saturday, January 3, 2004

Just took a look at your screenshots, and they don't even apply to this discussion! You're doing fully customized GUIs, obviously you can do that with any language that supports graphics and can read mouse clicks. We were talking about GUI libraries that _save_ developers from having to develop their own custom GUIs.

Chris Nahr
Saturday, January 3, 2004

I didn't have to go looking for Java apps that don't suck, I have developed them. One of the three applications I listed was 100% developed by me. The other two were developed by programmers working for me.

It's not Java that sucks, it's the programmer(s). I'm fortunate enough to have four excellent Java programmers working for me. But the bottom line is that they are excellent programmers first, excellent Java programmers second.

Because Java is a fairly easy language to learn (albeit with a substantial API), it has a relatively low barrier to entry. So, you get a lot of less than good programmers attracted to the language because they don't have to worry about things like memory management.

Michael Connick
Saturday, January 3, 2004

Every single aspect (i.e. 100%) of the GUIs shown are developed in Swing. The majority of what is shown is simply created with subclasses of JPanel and JButton. A better understanding of Swing is needed before one comments on it.

Michael Connick
Saturday, January 3, 2004

Michael: Nice looking apps ... congrats :) Just curious, how long did it take you to develop the one you wrote by yourself?

jedidjab79
Saturday, January 3, 2004

The last one shown, with the skins, is the one I developed. It's an authoring system (it can display a variety of frame types) for delivering educational activities and includes a WYSIWYG editor. There's also an associated managment system and SQL database on the backend. Programming time for all components was roughly 14 months (first release). Content development of the educational activities and the associated graphics and sound actually took most of the time.

Michael Connick
Saturday, January 3, 2004

A little tangent that doesn't really help with the original question, but might be useful in this context anyway:

In my opinion cross-platform gui programming is a myth, or to be more precise, it only gets you close.

If all you want is to be able to *run* on other platforms and paint the right widget and frame shapes, perhaps your code for one platform will suffice. If you want it to seem natural to the users of that platform, you have to put in some serious platform-specific effort, or your gui will be second-rate on every platform except the one your programmers use day-to-day.

For custom business applications, a second-rate gui is usually good enough, and still better than the third-rate guis most business applications sport. For something like a shrink-wrapped spreadsheet, if you don't write a cross-platform core and have a native programmer for each platform write a unique native gui with the idioms of their own platform, you will always hear complaints like "MaxiSheet is really powerful, but it just feels like a BlatherOS application. It doesn't even use Dingleberries to show the Bazingas! So, I use MocoSheet, since it does everything I really need anyway." Of course such things only matter for an application the user chooses directly, like consumer stuff, so even for shrink-wrapped business applications the foreignness might not hurt your sales.

veal
Saturday, January 3, 2004

"Every single aspect (i.e. 100%) of the GUIs shown are developed in Swing. The majority of what is shown is simply created with subclasses of JPanel and JButton."

You're still missing the point. Correct me if I'm wrong but I don't think Swing comes with a pre-created round yellow button that shows a loudspeaker icon...

You were painting those controls yourself. It's immaterial that a library helped you drawing them on the screen. The whole point of cross-platform GUI libraries, as commonly understood, is that the developers should NOT have to draw their own control surfaces (though it's a nice extra if they can).

Quite the opposite, what I expect of a good cross-platform GUI library is that the application should look exactly like a native application on each platform, with all the standard controls & effects available there, with the same fonts, display quality, and display speed.

wxWindows for C++ and Python does that on MS Windows. I've yet to see a single Java application to equal that feat. They all either use hand-painted custom controls, like your programs, or else some Unixish GUI that's usually not up to Windows standards, and always looks & works noticeably different.

Chris Nahr
Sunday, January 4, 2004

(When I say "all" and "exactly" I'm talking about the ideal situation -- some compromises are acceptable, of course, but IMO no Java app I've seen is in the "acceptable" range.)

Chris Nahr
Sunday, January 4, 2004

Michael,

That's great that you were able to make such nice looking applications. Because I haven't downloaded them and installed them, I can't speak to how well they run. It is worth pointing out that your interface is very unique to your product. You would have had the same issues of needing to draw your own widgets no matter what platform you chose to use.

That doesn't apply very well to what I do. I want a very standard UI that has controls people are familiar with. I'm not interested in drawing my own. My margins are low, and I don't have the time to invest. I do also have to agree that while it's probably possible to make good application distributions with a built-in JRE, it is a rarity that this is done. My shop, anyway, stays with C and C++.

Clay Dowling
Sunday, January 4, 2004