Slashdot Mirror
Cross-Platform GUI Toolkits (Again)?
Futurepower(R) queries: "It has been 2 1/2 years since the previous Ask
Slashdot about GUI Toolkits. There were many helpful comments then, such
as this
one. Since then, Slashdot has discussed wxWindows vs. MFC and considered the book, Creating Applications with Mozilla. The best comparison table is
apparently still the GUI Toolkit,
Framework Page. Which is the best cross-platform GUI toolkit that provides
native look and feel? Which is the best overall? What IDEs and other tools do
you use? What are the problems?" Slashdot also had a match-up between GTK+ and Qt, but some of you might have missed that one. How have recent changes in this ballpark changed your feelings on the issue?
The Fast Lightning Tool Kit is very nice. I've used it on Sun OS, Linux and Windows. Compiles between platforms without much change to the source at all...mostly its the system calls that needs to be changed, nothing related to the GUI.
I personally think that Cocoa and GNUstep deserve to be mentioned among the best-designed toolkits around. Both follow the OpenStep guidelines rather closely, and the OpenStep guidelines are very well-documented on Apple's site.
GNUstep is also quite portable -- I have used it on three or four platforms, and have no doubt that others work great. My only complaint about GNUstep is its idiosyncratic build system, but I believe that's a left-over from NeXTSTEP, the precursor to OpenStep.
If you're interested in learning more about Cocoa and other OpenStep-compliant toolkits, check Apple's developer site and the Hillegass book, published by AW.
unixkb.com -- articles on practical Unix issues.
Swing is functional and cross-platform, free-beer, and widely understood.
I have discovered a wonderful
Nice and portable and reasonably consistent feel and appearance.
And for those who like to use it in a scripting environment, use it as is. Use it with Perl, C, C++, etc...
I stick to walls...
If you're talking about true cross-platform compatibility, combined with ease of development and deployment, then Tcl can't be beat. It's always been good, but recent developments, such as the Starkitpackaging and runtime system, make it a hands-down winner.
It is hard to admit it, but when the mono team gets windows forms working correctly, C# and .NET are going to pick up a great deal of momentum, specially in the cross-platform GUI development area.
At my new employment I had a project that needed to be cross platform. I was itching to use Kylix, however it wasn't due to be finished for another 8 months. Looking into the details I saw that they built the corss platform support on QT.
After checking out the QT tutorials I was immediatly hooked. QT is intuitive; I can't think of many other APIs I would grace with this description. In addition to being well thought out it has a superb implementation. I've been using it happily for 2 years.
The only thing I miss is the strong third party component community that Delphi/Kylix has. I'm a huge fan of "buy don't build". You can really put quality touches on your app by finding the right component someone else has already made.
-R
available with Eiffel Software's EiffelStudio development suite. It's called Vision2 and provides platform independent look and feel by using a bridge pattern to separate an interface layer from the underlying implementation layer (which uses the Win32 API and Gtk+ for the platform dependent stuff).
You can download the full EiffelStudio suite for linux (and Windows) and use it free for non-commercial software, Vision2 is included and is available here, it's free!
-- You see what happens when you have fun with a stranger in the Alps?
The author has spent a lot of time looking at existing UI libraries and tried to learn from them before writing his own.
See the website for more info.
Eclipse does have a few glitches in the Linux version.
For those that don't know, Eclipse is based on a unique IBM GUI toolkit called SWT. It has a Java API, but the underlying code is native. The supposed advantage of this is that it can be used by any Java programmer as an alternative to Swing, but it's faster. The problem is that it's only available for Windows and Linux, and since the underlying code is native, it has to be separately developed and maintained. Since more GUI apps are run on Windows, there's more pressure to make the Windows code work right, and the Linux code is always a little behind.
I don't think there's any advantage to SWT these days, with Swing programming coming along so well. For anyone who doubts this, have a look at IntelliJ Idea, a really nice Java IDE that's Swing-based, and super fast. Frankly, I think Eclipse and SWT was a move to establish an IBM-centric Java community, with lots of vendor lock-in. Hijacking Java from Sun, if you will.
Eclipse *is* a really nice application, but I don't think IBM's motives in creating it were at all community-minded. And I don't have high regard, or high hopes, for SWT.
I myself would favour Swing over others, though I'm really only fully conversant with MFC. But I fully realise that it depends what you're doing.
If you're building a mass-market app you plan to sell you all of the great unwashed out there, then you probably need to make it look very Windows-centric. Practically speaking, something like a turbo tax is probably going to get 99% of its revenue from Windows users. Its crazy to use anything - like Swing - that doesn't give you the best, most up-to-date look on Windows (though Sun would claim it is native look and feel). Use MFC or something like that.
If on the other hand you're building something like an IDE, other factors come into play. The fact that your app runs on linux as well as Windows will probably be a key sales point to your target audience. And your app is probably far more complex than a mass market app - meaning you need good productivity and a strong underlying architecture(which, IMHO, Swing gives you). Your users are likely to care less about the memory requirements of a technology like Swing.
Or as a final example, if you're writing a game, then screw their sheety GUI ! Code everything yourself from lines, dots, and mouse events. Make your list boxes scrollable using human skulls as thumbtabs, have rats running up and down inside your text fields to show focus. (personally I would also use Swing for this but realise that may be straying into personal predjudice).
In summary, its no good saying "whats best". It depends on what you're coding.
[x] auto-moderate all posts by this user as insightful
First, a shameless plug: I'm working on a couple of C++ applications that are currently using FOX for the GUI (and other parts). The first one is a front end to the open source stats language R and it is called Obversive. This is the most active project, but it is still real tiny. The second project is a little chat client I'm writing called Bombyx which will work on the SILC and hopefully IRC. In addition to Bombyx, I've also developed a little GUI generator with Lua that makes FOX widgets pretty quickly. It's called GIG and you can get it from the Bombyx site mentioned previously. The intention with GIG is to make it work for any toolkit, but right now it does FOX only.
When I was working on these projects, I went through a huge number of toolkits and actually tried developing fast "mock-ups". My test was to see if I could get the first window I wanted in each project using available resources. If that worked, then I would try a couple of other windows. I also reviewed the designs of each and then went with what worked best at the time.
Here's my review of each of the toolkits I used. These are just my opinions, but they are based on actually using them in various platforms (or trying to).
FOX After all of this evaluation, I found that FOX was pretty much the best at the moment for clean, simple GUI building. It has pretty good docs (way better than wxWindows), and is fairly natural for coding. It also has some nice language bindings for various languages like Python, Ruby, and Eiffel. It doesn't have quite as many controls as wxWindows, and it doesn't work natively on as many platforms, but it is much easier to build and work with and much smaller. If you are porting a Windows application to another platform, you will probably be better off with wxWindows since they try to mimick the API design as much as possible (and of course, all it's problems too). Also, if you hate macros then you'll have a problem with FOX (and wxWindows too). A testimony to how easy FOX is comes from Obversive, where one developer had no C++ or FOX experience and has already created several complicated controls. Another developer has good C++ skills, but only worked with KDE previously. He not only developed an excellent Twin Table control, but also added lots of great features to it and in very little time.
FLTK I did the original work on Bombyx with FLTK. FLTK is a nice library, but it was just missing too many widgets to be useful. It was also rather buggy and it was a real pain to do delegation. There are, however, two really nice things about FLTK: no macros, excellent GUI builder. One of huge problems with ALL other toolkits I've ran into is that, when the developers start to make their GUI builder, the decide they need an entire IDE. I already have one thank you. I doubt some OSS project is really going to out-do my tool chain right now, especially if it's also working on the widgets. Just give me a simple builder please. FLTK got it right with FLUID--their GUI builder. It's real easy to use, super fast, and does one thing well: build interfaces. It was a little weird at times, but I checked out the latest and it worked great. Also, FLTK does not use macros for messaging which is nice for the C++ purists.
Cocoa I love Cocoa, but, Apple made a huge mistake by making it a MacOSX only beast. I think Apple could rule the world if I could spend my time writing my apps with a nice UI, great tools, and an easy language (Objective-C), and then click a button and have a Windows, Linux, HP-UX, and Solaris binary. You could do this with the original NeXT stuff, but Apple crippled Cocoa and friends. So, I reserve Cocoa for other useless programming that I only do on my MacOSX. There is GNUstep, but I couldn't get anything to work with it, and half the fun of Cocoa development is using Interface Builder (IB). BTW, IB is another GUI builder that is excellent, and also does just GUI building. Let's hope the wxWindows guys figure out this pattern and write a small GUI builder rather than their entire IDE which nobody seems to be able to compile but three dudes inside the cabal (sorry, it really burns me).
wxWindows I must say that wxWindows has a ton of nice widgets (I may steal their HTML widget) and works on a huge number of platforms. But, I kept getting burned in three areas: docs, dependencies, and bugs. Their docs are horrible. You have to hunt around the net looking for tutorials which are not very good anyway. Half the example applications in the distro don't even work so you can't rely on them, and it's just really hard to figure out what to do. I also hated having to add a billion other libraries to my build just to get wxWindows to work. I found it a problem when linking my application took longer than compiling all the files from scratch. Finally, just about everytime I went to use some widget, I found some bug or limitation that made it unusable. They have improved quite a lot from what I have heard, and people really rave about it, so I think everyone should give it a try. One thing also that annoyed me about wxWindows is that it does not support delegation very well. All the other toolkits I used either support delegation easily or practically require it. In wxWindows, I spent the better part of a week just trying to get one simple delegation design working and couldn't do it despite lots of help from people on various IRC channels. To me, things are broken if I have to subclass every time I want a widget. The wxWindows XML based resource files are supposed to fix this, but I won't hold my breath.
JFC/Swing The original version of Obversive was done in Swing with lots of other goodies. Java is my primary work language, and I really wanted to use it on the Obversive project, but we just kept running into performance problems. Frankly, Swing is just a P.I.G. and is really hard to code. None of the GUI builders available we tried proved to be that useful, and eventually we dropped it becuase it was just too huge. Ironically, we were able to prototype an almost complete GUI using FOX which runs on Linux, *BSD, Windows, and MacOSX (through the XDarwin or Apple X ports) in about 3 weeks time. This was mainly in part due to the slick design of FOX and simplicity, and partly in part because of the GIG code generator I put together. Oh, and we looked at SWT, but balked at the Linux or Windows only (and the fact that the flagship, Eclipse, ALWAYS crashes on Linux does not make me happy).
So, that's my experiences with these toolkits. I hope that helps answer the question, and I hope the reply wasn't too long. To summarize: Use FOX if you need C++ and good design. Use wxWindows if porting from MFC or if native controls are important. Use Swing if speed is not a problem, but cross platform really is. Use Cocoa if you only care about MacOSX and need to get something out quick. I actually prototype some UIs in Interface Builder on MacOSX, which says a lot.
I have been using Qt for the last 1.5 years to develop an application for post-processing of segmented (medical) image data as part of my master thesis. The application is available under the GPL at sourceforge
:-)
During development one major disadvantage of Qt has surfaced, and I think it shows that the Trolltech has choosen a terribly wrong solution to a complex problem.
In order to support their signals-and-slots mechanism (which is an elegant concept, and allows for easy implementation of both the model-observer pattern and the mediator pattern) they have added two new keywords to the language, namely signals and slots. In order to support these you _HAVE_ to run a preprocessor called moc (Meta Object Compiler) for your program to link. But moc does not support templates.
Mostly we have managed to work around this limitation by having a non-template superclass which declares the signals and slots (luckily slots can be virtual) and then have the template parts in a subclass, but this leads to unnatural class hierarchies.
Other libraries have managed to support a signals-and-slots mechanism without such an ugly hack. Both Boost.signals and libsic++ implement them. However their syntax is not as nice as Qt's. If C++ really need even more syntax is of course another question
While not all applications rely upon templates, they have some interesting uses, and if an applications first starts to use them, most classes easily ends up as template classes. See the book Modern C++ Design for "new-school" uses of templates. This could easily be the direction C++ development is headed, and it's a shame Qt will not be able to be a part of it.
Remember Pascal? At one time, Pascal was the major development language. Pascal was taught at all the universities. But, an amazing thing happened. In a period of about 4 years, Pascal died. Hundreds of thousands of people had spent millions of hours learning the particular quirks of Pascal and of Pascal compilers. All of that time was lost.
If you have never lived through the loss of a major direction in your life, you may not even realize it can happen. The people saying I'm a troll in this thread probably haven't seen technology die.
Remember Powerbuilder? At one time there were about 1.5 million active Powerbuilder programmers.
No really, is Java dying? Now, I'm seeing, or think I'm seeing, the same thing with Java. The expected energy and support and standards have not appeared. Or have they? If I'm wrong, prove me wrong; I would like Java to be a success, that would simplify my choices. We bet part of our lives on our choices of specialization.
What frightens me is that there is so little support for GUIs in Java. When programmers don't work to improve their tools, they are consciously or unconsciously deciding that the technology does not warrant improvement.
I've seen Java programs that are unacceptably slow.
Sun mismanagement of Java makes people look elsewhere. The world is beginning to realize more fully that proprietary means, "I'm a dog on a leash; I'll bark whenever you yank my chain; please abuse me."
When you use Java, or any language in a way that is not fully compiled to native instructions, you give away your source code. Sure, what you give away is without comments or variable names, but nevertheless you may give away important routines. That's fine if you intend to make a gift of your work to the world; you should have the option not to do so. There has been surprisingly little work on full Java compilers; until Java has acceptable compilers, it hasn't proven itself. Is GCJ mature?
Visual Basic and Perl are written in C. Should it bother me about other languages that they are written in C or C++? Why not eliminate the middleman? Can an acceptable result for application development be achieved using something like Boundschecker and avoiding pointers and using automatic garbage collection where appropriate?
Slashdot has a moderation problem. You can't comment on and moderate the same story. So, moderators by definition moderate stories that don't interest them much.
Bet wrong and go back to being a novice. As I write this, the parent post has been moderated Flamebait=1, Insightful=1, Overrated=1, Total=3. The question is a real and important one, not a troll. When you pick a technology, you lose part of your quality of life if you are wrong; you go back to being a novice at something else.
If you know better, educate me. If I'm wrong, and you know better, educate me. That's the entire purpose of Ask Slashdot.