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.
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 your looking to Java for cross-platform development and cli is not your thing, Eclipse is a nice IDE that works nicely on windows and linux. Its also open source.
Okay, I'll bring it up now: IBM's SWT is great. I've been using Eclipse lately under gnome2 and it's wonderful. Nice native look and feel (great anti-aliased fonts) and very responsive.
If you don't know, Standard Widget Toolkit (SWT) is a java GUI framework that uses JNI to call the native OS windowing API. It's an excellent example of how java can successfully be used for client desktop applications. IBM developed it for the open source Eclipse IDE.
Who said Freedom was Fair?
For the kind of GUI-I-Wanna-Slap-Atop-A-Database, I like to use Tcl/Tk. Works great for programs where you just want to have something quick, rapidly prototyped AND cross platform.
If you really want a well orchestrated OO GUI toolkit (with the exception of some nasty hacks), QT is a great thing to couple with C++. I know there are many out there that cry foul at the MOC. For the uninitiated, QT uses a macro processor to add a few keywords to C++ for their Observer(or Publish/Subscribe) pattern. I feel that these extensions are minor, and do not significantly detriment the portability of the code. That is, unless you are insane and derive EVERYTHING from QObject - then you are going to be heavily dependent on QT. In a well abstracted interface, your main code tree shouldn't contain much, if any, GUI code.
I have a lot of respect for GTK+, but it just isn't for *me*. GTK programs do generally feel a little more responsive on slower hardware, and are generally lighter weight (being mostly pure C), but the question seems to revolve more around cross platform programs, and GTK doesn't seem to integrate very naturally with the other platforms - at least not the programs that I have seen.
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.
I've been coding for wxPython for months now. It's a great gui library, it's fast, it's portable, and it has tons of controls. It's flexible, and it's free. The docs are good, too. I cannot imagine switching to pygtk or pyqt at this point.
My only bitch is this: the development model all but forces the programmer to reuse thru inheritance, not composition. I realize that inheritance was the preferred method of OO reuse when wx was originally conceived and written, but reusing wx types thru inheritance is painful because it leads to lots of (very similar) code.
Trolltech's QT costs $1550 each, per developer, for commercial use on Windows and Mac.
QT versus Java (PDF file)
QT versus MFC, in English (See the French below.)
QT versus MFC, in French (MFC contre Qt)
It looks like Qt does native widgets everywhere. I haven't coded with it, but source compatibility bewteen Windows, OS X, X11, and Qt/Embedded seems pretty promising. But personally, I'm still using the tried and true cross platform GUI toolkit known as HTML :)
__
Choose mnemonic identifiers. If you can't remember what mnemonic means, you've got a problem. - Larry Wall
Actually SWT has several really nice advantages. I agree that Swing has improved a lot in the past few years, but Swing apps are still not native apps and users can certainly tell the difference. SWT applications are essentially native applications not only in appearance, but also in functionality. There will always be little keyboard shortcuts or imcompatibilities that Swing will miss that SWT programs inherently account for because they use the native implementations underneath. SWT apps are generally considered more responsive than Swing apps. As cross-platforms toolkits go, the one-to-one mapping design philosophy has also been embraced as a great idea from an architectural stand point. (see http://www.eclipse.org/articles/Article-SWT-Design -1/SWT-Design-1.html for reasons why)
The SWT is not available for only Windows and Linux. It also works on Motif (for Unixes), Carbon (Mac) and I think they even have one for and embedded platform named QNX.
Also, IBM had no intentions of creating an "IBM-centric Java community" with the development of SWT. SWT was originally created to be used in Eclipse and the simple reason why they didn't use Swing was because Swing was horribly slow and ugly back then. I would say that it still is fairly slow and ugly, but one might argue that if Swing was in its current state when the Eclipse project was started that IBM may not have bothered to create the SWT.
on PyQT:
http://www.opendocspublishing.com/pyqt/
Python: cross platform
QT: cross platform, native-working widgets.
QT, however, isn't free for commercial use.
S
Except when you introduce "themes" a la 99% of X users or more and more Windows users (as XP is adopted). This renders Swing more or less useless if you want the application to blend in to the rest of the windowing system.
Additionally, Swing is still all tied up in The Way You Code It. We have an application that uses Swing but we have to force it to use the Metal/Steel/whatever-it's-called look-and-feel because we had expanded the widget set to do various other things that just Didn't Work when they were in the Windows look-and-feel. This is the reason why i coded it in AWT first, because it was supposed to run on Windows, but because Sun never fixed the bugs (i think there are still plenty in their bug database i entered that are still open or ignored) we had to convert to Swing... and now we have a weird-looking app for both Windows and X users.
One of the KEY problems in GUI development that i see is fonts. Fonts are fucked up and all different between the windowing systems, and this was precisely the reason why we needed to implement our own widgets in Java. The names of fonts are different, the sizes they are are different, the way they're rendered is different... Yuck. We ended up having to make a flakey, probably illegal font pack for Linux, made up out of MS fonts, just to use Linux as our development platform, and even then they didn't render exactly the same (especially when we needed a widget to be a specific fixed width). From what i understand, MacOS does it different all over again. This is even a problem in supposedly cross-platform HTML too. Fonts just suck.
I could go on forever about this, about how GTK applications look like shit under Windows (they don't "refresh" or "paint" properly for starters), most every client app written in Java that's more complex than a JDBC form looks weird under Windows, ugh. I think the original poster is conceptually correct in what he was saying. Unless MacOS, X and Windows all start using a common method to implement themes and font rendering, cross-platform GUI development is going to continue to be utter hell.
I got a sig so you would remember me.
After using Qt for a couple of years, for both open source and commercial software, I can say it does the job admirably. It is easy to pick up, and using it is fun :)
Qt is not necessarily only for GUI. There are lots of convenience classes available to make your life easier doing cross-platform work: Text/Unicode handling, image, containers, networking, database, XML, etc. Many of these classes are highly optimized. I use Qt even when I'm writing a console app.
Though I have not used Java, I am told the API is very similar in style (to Swing?). The upside to Qt is that it is compiled and uses C++, so it is fast and you can mix and match system code. A common myth about cross-platform software is that you must cater to the lowest common denominator, which is absolutely not true with Qt.
Even if you are doing development for a single platform, you may still want to use Qt. It is generally easier to use than whatever is native (though I have heard very good things about Cocoa/ObjC), and it secures you that 'out' in case you want to port later.
For some examples of cross-platform projects using Qt, see Opera and Psi.
The low-level Windows API solution is the each object has a window handle and the interface that goes with that -- a WinProc. That means every window object has to expose the same, complex interface with a zillion Windows messages to every other window object it can come in contact with. This leads to (what some people) consider ugly -- the Giant Switch Statement in C implementations or those even uglier message map macros for C++ MFC (I believe wxWindows uses message maps too).
The Grand Quest is some simple mechanism for making direct signalling connections between objects without breaking encapsulation -- exposing the inner workings of every object to every other object: kind of like how to be on the Internet and disclosing your e-mail address without losing your privacy or worse.
The solution is to create some bridge class -- a courier with a personal knowledge of the recipient but a courier which publishes only a very generic interface to those seeking to contact the recipient. In Delphi that courier is an event type, in Java, it is an inner class with an ActionListener interface, in C# it is a delegate.
Qt has this mechanism called signals and slots, and to pull it off they had to extend the C++ language with this macro processor called MOC, and this has the BVDs bunched of C++ purists because they are in effect extending the language.
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.
And I mean it. You would probably be hard pressed to find even one correct sentence here. For those interested, here are a couple of refutations.
X is based on a networking concept where anyone can access anyone else's screen as a network resource.
Wrong. Only those with permission can access it. But that would be programs, not people. For people to access the screen, they would have to physically be there, and that is no different than any other windowing system.
This leads to multi-threading issues as it is possible for two people to use the same desktop, even same application, simultaneously
Wrong. While many people can sit in front of one computer if it's enough space for them, that doesn't mean anything will be more multithreaded. Also, the display server will have to do exactly the same kind of resource multiplexing as it does on windows (whether the apps displaying windows are executing remotely or locally is of little difference, they are still in different threads and usually also different adress spaces).
As a result, toolkits that have their origins in that environment like GTK and wxwindows have strong multi-threading support not to mention strong networking support.
Wrong. Few, if any, X11-toolkits support multithreading. This is a direct result of the age of the X11 core libraries, which themselves does not support multithreading. Most everyone agrees that this is a bug, but it's also one that's hard to fix.
OTOH, Windows was built around a single user concept, which from a networking perspective is more secure because a person's desktop isn't a networking resource (but that's neither here nor there).
Wrong again. How do you think those Citrix farms work? Windows isn't built around a single-user concept any more than Unix is (I am talking about NT/2000/XP of course). It might be the case that your typical windows distribution is only useful for one user at a time, but the underlying technology very much supports several users. As for not exposing anything on the network, sure that makes it more secure. Nobody in their right mind allows X11 through their firewall. But windows has plenty of other security holes.
This results in the base windowing subsystem's reliance on processes as the fundamental object of execution (as opposed to threads).
Again wrong. XFree86 uses a simple request-response loop (no threads or processes). There do exist multithreaded X-servers however, but not for the reasons you say. Mainly, if they are multithreaded, it is purely for performance-reasons.
Whether processes or threads are used, have absolutely nothing to do with networking, but more to do with taste, and programmer preference.
As for windows, it uses threads. Lot's of them, so even there, you are wrong.
So toolkits built upon Windows (MFC, OWL, QT) are able to harness Windows's windowing support in a way that more easily and effectively takes advantage of the features of the subsystem.
I fail to see any correspondence between the "cause" and the "conclusion" here. In any case, it is wrong. On the other hand, windows is a more mature and stable GUI platform. And this is more than enough to explain why X11 GUI's generally suck in comparison (even when they are cross-platform).
Attempting to port one toolkit from its home platform to a foreign platform leads to problems of "look and feel". AWT and Swing are prime examples of toolkits that look strange whereever they are used. Likewise, wxwindows feels funny running on Windows and GTK looks funny. Hell, MFC doesn't even run on X.
True. However, MFC apps can (more or less) run on X11, if you want to pay enough for it, and you really need it. There are companies selling that sort of thing.
What this all boils down to
Well, the only thing it can boil down to, is that either you are a troll, or someone seriously likely to talk out of his ass about anything he doesn't know about.
The final "conclusion" is obviously right, but I fail to see why you needed all the errors above to "support" it.