Slashdot Mirror
GUI Toolkits for the X Window System
TeachingMachines writes "Leslie Polzer has written a nice summary of the current state of GUI Toolkits for the X Windows System (article title of the same name). Those of you who are planning to spend hours and hours scouring the Internet for a mature cross-platform GUI toolkit may save some time and trouble by reading this summary. Leslie's review covers the pros and cons of using GTK+, Trolltech QT, FLTK, wxWindows, and the FOX Toolkit."
It still takes a really long time to find documentation on writing stuff for X in the first place. For instance, I was getting into creating a window manager at one point and found it extremely difficult to find documents about how to acutally program for X. Widget toolkits are not enough in some cases. Some books about low-level X programming are at:
: //www.pconline.com/~erc/advxwnd.htm
http://www.pconline.com/~erc/xwind2nd.htm
http
Unfortunately, I've lost the URLs for the X API docs and containing really good example documentation on X Windows programming in C. If anybody has these URLs, I'd appreciate it, since it took me several days of searching to dig them up and I can't find them anymore (harddrive crashes suck).
www.sitetronics.com/wordpress
No, I think this is different than most libraries. In general, commonly used libraries are already in the proper directory, ready to be used. But windowing toolkits aren't generally installed by default. Specifically, if you are compiling code that uses one of the more obscure windowing toolkits, you have very little chance of already having the proper libraries in place. In which case you will have to go hunt them down.
Slashdot Syndrome: the sudden, extreme urge to correct someone in order to validate one's self.
Cross platform, native widgets.
Combined with python it is very simple and easy.
I wouldn't make commercial apps, but for small development, it's my choice.
He missed the best: GNUStep.
GNUStep uses Objective-C and is a clone of the OpenStep API's and is pretty stable.
To write a simple Application you do not have to write that much code any more.
The author claims it is not free software. The FLTK site claims otherwise:
FLTK comes with complete free source code. FLTK is available under the terms of the GNU Library General Public License.
We have ammended the LGPL to explicitly allow static linking of FLTK (or any modified version of FLTK) to your software. The LGPL is not clear on this and we definately want to allow it.
1) Tk is very fast to develop with. You can get good gui's out quickly.
2) So now you want to do a complex, involved gui? You can do that too. Don't like stuff that was thrown together quickly by people who don't know anything about GUI design fool you. It's hard work, and it takes a different set of skills. Just because Tk made GUI programming available to just about everyone, don't judge it on the results of everyone trying to do GUI's!
3) Tk has been around for a while, is well tested, well known, and well built. It is the toolkit of choice for Tcl, Python, and lots of other languages.
4) Of course, it is open source, and lots of people use it and know it. If you want to improve it, you can.
http://www.welton.it/davidw/
I can't believe this author missed the one toolkit that's been making so much wave in the last year, namely Java/SWT.
It's the toolkit used to create the Eclipse IDE from IBM, similar in approach to wxWindows...i.e. renders using native widgets on each platfrom (win32 APIs on Windows, GTK+ 2.0 on Linux, Aqua on Mac OS X), but with the same common API on all platforms.
Did I mention coding in Java is much easier than fighting with ancient macros in C or C++?
Plus, SWT apps start up real fast and consume much less resources than the infamous default Java SWING toolkit. Just look at the difference in responsiveness between Eclipse and NetBeans (I call it the Molasses IDE in tribute to its speed).
SWT is the future of Java GUI and because it renders with native widgets it's the way to go for the future.
Did I mention it's open-source and 100% free on all platforms, including windows (unlike Qt).
Plus...you get access to all the standard Java libs (db access, xml processing, web services, threasing, etc...)
Have you ever tried to program using the perl bindings? I have done it in the past and was extremely annoyed by the fact that it is a non-stop moving target. It also broke quite often. I ended up abandoning the entire stuff.
Yup, sure have. I've been working with this app for going on three years, producing useful releases every 4-5 months or so, and haven't run across a "moving target" in Perl/Tk. Aside from bugfixes, I haven't had to go back and change any of my code or work around any brokenness in new Perl/Tk releases.
Granted, my app doesn't tax the outer limits of the Tk bindings, but for what I do, I've found Perl/Tk to be a stable and adequate cross-platform toolkit.
Many have enjoyed how easy Tk is to use and how x-platform (and
x-language) compatible it is, much easier and more stable than other
toolkits mentioned.
A common complaint has been the default Motif look and feel on unix
(this is easy to change, but many don't bother changing the
defaults). This is about to change. Tk 8.5, currently in development,
is going to represent a major revamp of Tk. Basic things like updated
default look and feel as well as enhancing the core widget base (there
are 100s of widgets for Tk, but only 15 in the "core").
This is also meant to target all Tk users (not just Tcl users). There
are lots of widgets out there only available to Tcl/Tk users that
could be made available to Perl/Python/Ruby/R/Lua/etc if a better
framework were used so widget authors understood the basics of having
their widgets used by multiple languages. Numerous other enhancements
are planned, all to be done on a tight schedule (we don't like waiting
for software). You can see the a wiki for this work being built at
http://tcl.projectforum.com/tk/
http://www.welton.it/davidw/
Qt:
- most polished GUI of the bunch, great documentation, great portability, looks great.
- typesafe callbacks
- smallest learning curve - very easy to use.
- downside: price, MOC preprocessor, very long compiles.
- recommendation: if you have the money - go buy it.
FLTK:
- perhaps the fastest and has the smallest memory footprint of the bunch.
- small size comes with a price - the look and feel is noticably "off" and often you get non-standard widget behavior.
- void* based event callbacks
- fastest compiles
FOX:
- programs look quite professional
- non typesafe events void* pointers that are a royal pain in the butt to use, and are very poorly documented.
- lack of virtual functions for most GUI classes - must use table dispatch for each new class to override behavior.
- only supports UNIX (X11) and Windows
- only has Windows 2000 look on any platform, but looks quite good nonetheless with minimal flicker
- small user base
- no CVS access - maintained by one individual
WxWindows:
- supports the most platforms, has native look.
- large community of support
- many interpreted language bindings
- different behavior on different platforms
- widgets flicker like crazy
- not very stable in my experience
More importantly... What, no GNUstep?
:)
It's amazing how much GNUstep is overlooked given that it is the only toolkit whose featureset can compete with qt. Just like qt, GNUstep is a full framework covering much more than simply building a GUI, and can thus be the foundation of an entire application/environment. The OpenStep frameworks (of which GNUstep is an open-source rewrite) address everything from low-level primitives (collection classes, advanced memory management with garbage collection) to networking, file operations, GUI operations (with a graphical IDE and GUI builder modeled after NeXT, now Apple's Project Builder/Interface Builder) and more.
If more attention were paid to GNUstep, it would get the usage that it deserves. I find it superior to almost every toolkit except for qt (with which it competes neck-to-neck in terms of featureset and consistency), and any Mac OS X or OpenStep/NeXTStep programmer will give a glowing recommendation. Plus, it uses Objective-C