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's far more easily cross platform than the competitors. It's a rich GUI toolkit, not limited by least-common-denominator weirdnesses, and backed by a world class rendering layer (java 2D).
Todays Java is not at all what old Java was. It's far faster, and only getting faster with each release, than in the past, far more reliable, far more complete, etc.
This made the article useless. I wonder if he has ever tried QT. It just works! No futzing around. He is biased because you have to pay for the windows port.
I need to write GUI code that works on all Linux, all HP-UX, all SUN Solaris, all SGI platforms without requiring more than a simple "make".
Our customers would not like it if I told them to find and install version 1.2 of GTK and stuff like that, because in all honestly, on any platform other than Linux most of these toolkit libraries have no simple install mechanism and tend to be buggy.
So Xlib all the way... Simple and it runs on even a 10 year old version of Linux.
I personally think Qt is made irrelevant by both of the others because they are not missing anything Qt offers. The tools that come with Qt may not be bundled with them, but comparable tools do exist and can be used free of charge, and most often as Free Software. Qt's biggest weaknesses are its relic called "MOC" and its business orientation. Yes, it's GPL, but not for MS Windows, so you're not really free. FOX and (especially) wxWindows offer similarly advanced sets of widgets and techniques, so you might as well throw Qt away. In terms of portability, it's the same, and wxWindows even adds OS/2 portability. Believe me, I don't want to be unfair to Trolltech or upset dedicated Qt developers. I tried to be objective, and that's my objective conclusion. Maybe we can discuss this point in the comments for this article.
There is a disturbing trend of recent articles that engage in Qt/KDE bashing. Can't help wondering whether it is really a coincidence or not. For instance, here's another freshmeat editorial from a few months back.
However, for those developing low-level X programs such as window managers and XIM servers that need to meddle with (say) ICCCM details, you are probably better off just using Xlib --- just like programs doing low-level I/O are better off using low-level functions instead of stdio.
Note that even in some cross-platform applications some non-portable stuff is needed in order to tune user experience, for example you may find a cool new feature of recent window managers accessible via ICCCM beneficial (albeit not essential) to your application, but toolkits haven't integrated such things yet. Therefore, it is very important that toolkits give access to low-level things like Window/Atom/Pixmap IDs so that bypassing it occasionally is possible. I don't know about others, but GTK does well in this regard.
Program in what you like...
Although programming in QT won't get it included into gnome and programming in GTK won't get it included in KDE.
A lot of apps people develop never see the light of day... I've programmed hundreds of little apps for the various companies I've worked for.. I programmed in what I liked.. and what I was used to...
Just because you need to create a little app with a textbox and a button doesn't mean you need to include the HEAVY libraries of gtk/qt/gnome/kde.
Just my thought.
ChiefArcher
Well, it looks like you also have one thing missed. Personally, I use wxWindows through python. To deploy, I compile everything to a windows native executable, which automatically comes with the necessary DLL's (http://starship.python.net/crew/theller/py2exe/). .exe more than 50%.
Also, for wxWindows, you can statically compile your programs, and then compress the executable, with upx (http://upx.sf.net), which by experience reduces the sizes of the
One way to avoid this problem of dependencies, and also to really boost the useability of your app, is to try hard to separate the GUI from the "guts" of the application, so it is reasonably easy to write multiple UIs (GUI or CLI) for the same application. Then you, or others, can come and develop new UIs for themselves. For example, when I started developing QuickRip, I began with a (Py)Qt interface. Someone requested a CLI interface, so I made the separation, and gave QuickRip two interfaces. Now some (Py)Gtk developers are adding a Gtk interface, because they don't want to use Qt. Lovely.
:)
Of course this approach is only usually worth it when most of the hard work is done in the guts, and when the UI itself isn't that much work to redo in a different toolkit. Nor does it work when you need a feature than is only available in a specific toolkit. But in many instances, it works fine.
So often there's no need to choose between toolkits... just choose them all!
When wxWindows gets decent support for toolkits other than Gtk+, it will make this even more trivial.
I can't speak to the technical aspects of QT, but TrollTech is a Canopy group company. For those that don't know, Canopy is also the parent of SCO. So tread lightly with QT, you never know if the insanity is contagious.
Where's my lobbyist? Right here.
Officially, PHP-GTK is at version 0.5.2 - "alpha".
I've written a 20,000 line software package in PHP-GTK and I can say that while GTK 1.2 is a bit funky, it's quite powerful and very stable.
Binding Gtk with the power and rapid development speed of PHP, using an IDE such as Dev-PHP results in an environment that's blissful, stable, and cross-platform.
The aforementioned application is currently in the midst of a very successful Beta on Windows, and once released, will be shortly released for Linux and Macintosh. To "compile" the software we used the Ioncube Encoder.
Gotta love it, eh?
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Exactly. The coolest part about TK (well, at least tkinter for python) is that you can "connect" a widget and a variable - someone edits the widget, and the variable changes value, automatically. Saves a LOT of code that would otherwise listen for event -> get widget value -> set variable value.
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.
Looking at the review FLTK has apparently grown up some perl bindings. This may be quite interesting...
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
"What you get when you download Qt 2/3 is the free X11 version ("Qt Free Edition") which enables you to write non-commercial applications for The X Window System. When you want to create commercial, proprietary, or non-free software, or want to compile your program for Windows or embedded systems, you'll have to pay for the Qt Professional or Enterprise version (both are quite expensive). Qt tried to specify this in their own license (the "QPL") because they felt the GPL could cause them some problems (please see freshmeat article #180 for more information). From Qt 2.2 and upwards, you can now freely choose between the QPL and GPL before building the libraries. That's the whole story; if you feel I missed an important point, feel free to correct me (Qt flames go straight to /dev/null, though). You can read more about Trolltech's licensing issues in freshmeat articles #170, #172, and the one mentioned above."
The author probably doesn't understand the GPL. All of the other tool kits distributed under the GPL can be used in commerical applications and SO CAN THE GPL'ed version of QT. You just have to accept the terms of the GPL to do so, IE: your application must be open sourced! In this sense QT has an avantage! If you buy their commerical license you may then close source your application. What they have done is allow you to pay extra to by-pass the GPL. How is this an evil thing? The other kits do NOT give you a choice, it's the GPL or nothing! Choice is good. QED.
QT != evil.
I agree. I came across GNUstep two months ago and was amazed by its incredibly simple API. I quickly made my first app, Charmap, a character map which uses Unicode.org's standards files to provide a wealth of information about any character. This was easy and fast because GNUstep provided solid Unicode/UTF-8 support from the start. While for example GTK was a pain to use until 2.0 with regards to non-Latin scripts, GNUstep at the same time had one of the most advanced string classes.
Not only is GNUstep concise and simple, but because Apple's Cocoa is also an implementation of the OPENSTEP standard, one can use Cocoa docs in GNUstep programming. This allows the programmer to tap into abundant resources online and in print.
If you're interested in what's going on in the GNUstep world, my favourite resource is www.gnustep.us, which lists the latest news and updates. I hope I don't sound like a karma whore, I'm just super-enthused about a fantastic API that doesn't get the attention it deserves.
GPG Key ID: 8C444E97 Fingerprint: E7BA D851 9714 8D97 C4F9 1777 8168 6913 8C44 4E97
I've done this multiple times. It's easy to do when you write from scratch with this approach, much harder to retrofit, but it comes down to the same issue....CLI apps tend to have a scriptlike UI, whereas decent GUI apps *demand* that multiple actions be available to the user at any time.
This requires that the application logic be converted into an event-driven state-machine model. Some CLI apps just can't make the transition without a rewrite.
Once the transition is done, though, you are right...you can make an app support almost any UI, including supporting a CGI interface for the web (assuming that's appropriate).
Premature optimization is the root of all evil
What the author claims as a weakness is actually a strength. Qt/UNIX is distributed under the GPL, which means that it can be used for free software development with the same freedom and same restrictions as any other GPL'd software library. However, if you can't comply with the terms of the GPL (because you are doing proprietary, closed software development) then with a normal GPL'd library you'd be SOL, but TrollTech gives you the option to pay them some money and obtain Qt under a commercial license.
This gives Qt a huge *advantage* over over the other libaries. By having its "business-oriented web site", it suckers thousands of large corporations into paying $2000 each for a Qt license. TrollTech uses this money to support the further development and improvement of Qt, which benefits both the commercial licensees and the free software, GPL users. Sure, they probably line their own pockets with some of the money, but no more than owners of RedHat, Debian, etc. Other libraries depend on volunteers performing intermittent maintenance and development, while Qt has an ever-increasing staff of paid developers.
+
My small company uses Qt for both free software development and proprietary software development, and we consider the $20K or so that we've sent to TrollTech to be money well spent!
"To be absolutely certain about something, one must know everything or nothing about it." -- Olin Miller
On the other hand, the interface to namespaces can be a liability in terms of complexity and hurdles to learning.
In either case I'd like to see more analysis.
also, the author misses a another buig point. I spoke to trolltech support about having to release code under GPL using the free liscense, and they agreed to only have it apply to code that actually included QT code.
For example, I have written an emulator which I havent open sourced yet, and 95% of the code is ANSI C++. Why should i need to open source the whole thing? I found them very accomidating in the fact that I would only have to open source the the parts that actually used the QT classes.
All in all QT is the best object oriented toolkit out there, they are a very professional company and a previsouly noted this should be a moot point when anylizing the toolkit itself.
proxy
The last 1.4 JVM I tried still uses 40 megs of resident RAM even for the most trivial Swing application. Also, "sufficiently fast" in your mind means "too damn slow" in most people's minds - get over it. Run a native app beside a Swing app - it's not even close. As for only having a single version of the JRE lying around - you must not run many legacy java applications certified to a specific JVM version.
EiffelVision 2 that is available for free download here It is definitely the easiest GUI toolkit to use I've ever encountered, no nasty callbacks here :)
-- You see what happens when you have fun with a stranger in the Alps?