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."
what no TK?
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.
No, he's not trolling. He's simply observing that there are a lot of GUI toolkits around and that most of them are not pre-installed on "your" standard off-the-shelf Linux box.
Before you misunderstand me: apart from the X server, my own box was built by me from the source and nothing but the source. Which is to say: I fully understand how libraries work and I don't mind looking for a bit of extra source if it looks like it might be useful. But for the very same reason, I also know from experience that some apps require a lot of effort to first collect all the dependencies and to then succesfully build them. And in my experience quite a few are not worth it if they require me to spend a few hours on tracking YAT (Yet Another Toolkit) first, especially if chances are slim that I will want to install another app that can live with (the same version of) the same toolkit.
Linux user since early January 1992.
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.
"According to http://www.trolltech.com/newsroom/investors.html the Canopy Group only has 5.7% shares of Trolltech while 64.7% are in posession of Trolltech employees with an additional 5% controlled by the Trolltech founders. One can hardly say that the Canopy Group owns or controls Trolltech." (Text from here)
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...)
Well, how many of you have really tested all mentioned GUI toolkits? I did that some time ago and ended up using FLTK, basically because of reasons mentioned in article: standard C++, free, light and stable Win32 support.
Bah. Not sure how that space got in there...
KDE MYTHS
"The area of penetration will no doubt be sensitive." ~ Spock
here is a link to the offical Windows XP visual style guidelines. I know theres some earlier versions as well, just do some searching on MSDN. Be aware that MS often violates these guidelines, so your developers may dismiss them.
yes, and the gtk/gnome developers would agree with you. thats is because gtk-1.2 has been pretty much deprecated for about 3 years now. please use gtk-2.2. it is far from ugly and has much greater cross-platform and cross-nationality support than any other GUI lib i have ever encountered.
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/
Use wxWindows. It uses GTK on Linux/Unix or Motif if it isn't availiable, and it uses the Win32 API on Windows. The only place it wouldn't look normal is if someone was using it in a KDE environment but most people using KDE are using Gnome apps as well and most distros use themes to make them look the same there.
Either that or build on top of Mozilla and use XUL.
The Anti-Blog
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
If you can live with a non-giant executable too, maybe a Starpack could interest you: a complete Tcl/Tk runtime system, plus your own app, all in one executable file, starting from under 1 MB. Zero installation.
See http://www.equi4.com/starkit/
I thought XVT was "out there" along with these other tools. Is it too small to show up on the radar, or is something else going on? (www.xvt.com for the curious)
Xentax
You shouldn't verb words.
The GUI Toolkit, Framework Page
at http://www.atai.org/guitool/
Free Software: the software by the people, of the people and for the people. Develop! Share! Enhance! Enjoy!
It's just not very well known yet because it's only been in open source since the fall of 2000. Prior to that it was a proprietary API for the use of Andy Green and his clients Learning in Motion, who used it for such products as the client-server educational database Knowledge Forum.
ZooLib is written in C++, and can produce native executables for Linux/X11, Windows, BeOS, and Mac OS (classic and carbon) with very little need for platform-specific client code.
It makes only very basic use of platform-specific code internally, which is kept encapsulated, so it wouldn't be very hard to port it to a completely new platform. Porting to a new Unix platform that uses X11 shouldn't be more than a day's work, for example. Porting to a platform that had a completely alien GUI API would be a few weeks of work for someone familiar with both the platform and ZooLib.
ZooLib's website has a piece I wrote about why cross-platform frameworks are good for developers:
Request your free CD of my piano music.
- GNOME Human Interface Guidelines
- KDE User Interface Guidelines
- From Apple, the Aqua Human Interface Guidelines and the pre-Aqua HIG
"The nice thing about standards is that there are so many to choose from"...Programming can be fun again. Film at 11.
I'm afraid your premise is incorrect as all the toolkits besides QT are under the lgpl or even less restrictive licenses (wxWindows, X11). This means your application does not have to be licensed under the gpl to link with it.
This means that GTK not only gives you the same choice, but doesn't require any money for choosing non-gpl.
(this post to be followed by umpteen rants on how the cost of QT is "worth it" in every single scenario)
-Mark
We have been evaluating GUI APIs for two projects we will be starting, and it came to QT, GTK+ and FLTK. It seems like we will go with QT despite the cost because theyre really a professional company with a complete API thats well documented and well used by large apps, uses win32 API very efficiently (see how fast opera the browser is) and comes in embedded versions too, which was one of our requirements. GTK+ for win32 is not mature enough although it competes with QT on unix quite well. It also has shortfalls with embedded systems whereas QT's qtopia has been used on many PDAs and theres a software base there.
I'm not worried about the UIC and tmake from QT, I just throw them into a makefile and it all works from a single 'make'. The plan is to distribute binaries alone.
The author in the summary tries to hide his beef with QT for a good reason. QT is the only one in the list thats not truly opensource compared to the rest, yet KDE has been competing with GNOME for a while. I think GNOME was started to counter KDE because it was based on a non-GPL API.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
The author doesn't even go into the respective DESIGNS of the toolkits either.
I've used several toolkits on several platforms in shipping, commercial software over the past 10 years, and taken a look at many of the "free" toolkits out there, and ended up going with Qt just because it has a superior (in my opinion) design.
I've spent more than a few hours trying to get these so-called cross-platform toolkits to build on Windows and Mac, and usually, they are half-finished implementations - just like you would expect from people not getting paid for their work. I'd rather not fiddle endlessly with code that doesn't quite compile, different build environments per platform, or just plain poorly-designed APIs. I was almost on the verge of writing my own GUI toolkit when I came across Qt - never looked back, blah blah.
wxWindows, in my opinion, has a design too similar to MFC - reliance on resource files, enumerated control IDs, message maps, etc just seems like a blatant rip-off of MFC, which is one of the worst toolkits out there.
Qt's built-in Motif-like layout, signals/slots, unreliance on resource files, great cross-platform build environment, and great documentation is amazing, and makes it well worth the cost for commercial development.