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."

Comments

what no TK?

[Anonymous Coward]

what no TK?

Re:what no TK?

[phrostie]

i noticed that as well. some of my favorite applications use TK/TCL. in fact i know of more that use tk/tcl than fltk or fox. if it works, use it.

Re:what no TK?

[DavidNWelton]

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.

Re:what no TK?

[andrewl6097]

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.

Re:what no TK?

[arivanov]

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...

Re:what no TK?

[lunenburg]

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.

Re:what no TK?

[__aavhli5779]

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 :)

Re:what no TK?

[Anonymous Coward]

Dupitty dupe dupe dooop!
Why look, it's one of Taco's posts. What a surprise. Might as well put the guy on welfare for all the actual work he does for his check.

Re:what no TK?

[shellbeach]

Have you ever tried to program using the perl bindings?

Yes, and personally I find it a joy to use, especially when compared to other perl GUI solutions. I have not found anything to be broken except remote DND drops under X.

But the big revelation for me was taking a highly complex perl/Tk gui I had written under linux and running that code on a Win2K system which had a default ActivePerl install ... and it worked perfectly!

100% cross-platform compatibility without changing a single line of code ... I happen to think that rather impressive.

Re:what no TK?

[d2003xx]

5) Tk provides very few widgets, compared to wxWindows and Qt.

One thing missed

[Doesn't_Comment_Code]

The one thing I don't like about toolkits (not mentioned in her list of cons) is that if you distribute the source code, whoever is compiling needs to have the toolkit.

I've tried to compile and install programs before and spent a lot of time trying to track down the toolkit libraries.

This is not a good reason to abondon using toolkits, but it is one negative aspect to take into consideration.

Re:One thing missed

[Anonymous Coward]

Not a negative aspect if you're a decent enough programmer to provide documentation as to where to obtain the toolkit, or provide a copy of it on the website from which you distribute the source.

Re:One thing missed

[mark_lybarger]

are you trolling or some such? every application that uses libraries needs those libraries to run. this is more a bad statement about use of libraries in general than anything to do with window toolkits.

Re:One thing missed

[Doesn't_Comment_Code]

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.

Re:One thing missed

[Sean Starkey]

This is a strange comment. It is like saying, "The one thing I don't like about C++ is that if you distribute the source code, whoever is compiling needs to have the compiler."

Of course you need the toolkit library if source code uses it.

Re:One thing missed

[Otter]

Back before Qt and Gtk crowded out everything else from the free Unix world, that was a huge problem. You'd find something promising on Freshmeat and then have to track down FLTK or WINGs or whatever else it required.

Seems like less of a problem nowadays, despite all the people complaining, "Now we have TWO toolsets to deal with!" Most Linux users have the KDE and GNOME (or GTK, at least) libraries available, and Windows and Mac users typically aren't in a position to compile anything anyway. It's tracking down the rest of the libraries that's more of a hassle. (Anyone know what I'm missing that astyle won't build?)

Re:One thing missed

[mce]

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.

Re:One thing missed

[cerberusss]

Well, I never had a problem with the compiler, but I DID have them with a library.

Re:One thing missed

[kbroom]

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/).
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 .exe more than 50%.

Re:One thing missed

[Anonymous Coward]

and Windows and Mac users typically aren't in a position to compile anything anyway.

Bullcrap. Mac OS X ships with everything needed to compile stuff, and also one of the best IDEs available. Interface Builder is simply beautiful as well, and comes included with every copy of Mac OS X.

This argument is ridiculous with Mac users around. AppKit simply rocks any other tookit's world.

Re:One thing missed

[Telex4]

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.

Re:One thing missed

[mark_lybarger]

normally you know that going into the effort. and i would guess that there's typically an easy way to get those things installed properly (apt-get, install shield, emerge, rpm, etc, etc). yes, if you're developing a kde/qt app, or a gtk+ app or a wxWindows app your user base will be slightly diminished. if someone wants the app, they'll get it. hell, the postgresql has a database management utility that's based on the wxWindows toolkit and has a nice and easy windows installer.

Re:One thing missed

[Anonymous Coward]

One would think that with someone that claims the knowledge of yourself would know how to type an HREF=

Re:One thing missed

[Anonymous Coward]

Bullcrap. Mac OS X ships with everything needed to compile stuff, and also one of the best IDEs available. Interface Builder is simply beautiful as well, and comes included with every copy of Mac OS X.

I'm on a TiBook right now -- yes, the MacOS development tools and frameworks are terrific. But my point is that the overwhelming majority of OS X installations (never mind the classic MacOS systems out there) do not have the development tools installed.

Re:One thing missed

[cheezit]

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).

Re:One thing missed

[Anonymous Coward]

Well, since what you are talking about doesn't even use X I don't understand what you are doing in this thread anyway.

Re:One thing missed

[Hatta]

If you had gentoo you wouldn't have to worry about all this. Portage automatically handles dependencies for compilation.

Re:One thing missed

[flounder_p]

This post got marked as off topic but I believe for some reading this could be a good source of info.
my mod 1:Interesting

bah

[Tirel]

He forgot SDL. It's very good, I like working with it, nice interface X11, etc.

Re:bah

[lightcycle]

Isn't SDL more of a toolkit for multimedia/games applications than a widgetset/graphical toolkit?

Re:bah

[jericho4.0]

That's what it started as, but as time has passed, it's grown into a reasonably portable/funtional framwork for apps, also.

That is, if you like making your own widgits.

Re:bah

[Anonymous Coward]

If only my database forms had the usability of a video game menuing system!

One could also recommend Shockwave Flash :)

X Programming In C

[dodell]

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:

http://www.pconline.com/~erc/xwind2nd.htm
http: //www.pconline.com/~erc/advxwnd.htm

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).

Re:X Programming In C

[Mandrake]

I highly recommend the X Programming manuals by ORA - particularly volumes 0 and 1. the rest are fluff, imnsho.

volume 1 does contain some documentation about writing a window manager, but it is really insufficient. if you're looking for appropriate documentation on what it should do, you can find the icccm documentation online somewhere (most modern window managers are NOT icccm compliant however)

Re:X Programming In C

[iabervon]

XFree86 (and X in general) actually comes with substantial documentation for all of this stuff, although it needs to get formatted during the build process. What's mainly lacking, I think, is a sufficiently detailed overview of the API. There's nothing that actually tells you where to look for the clipboard, how to tell things to the window manager, and even things like the best way to get a client-side color array to appear as an image.

Re:X Programming In C

[Anonymous Coward]

http://tronche.com/gui/x

has a good X api reference

Re:X Programming In C

[dodell]

As I said, there's a really great, linked API doc somewhere out there on the Internet and Google knows where it is. I'm trying to find it again.

Re:X Programming In C

[thames]

I have the following links (I'm trying to write a window manager myself... :-)
I hope these are the ones you lost:

http://www.xfree86.org//4.3.0/manindex3.html
ht tp://tronche.com/gui/x/icccm/
http://tronche.com/ gui/x/xlib/
http://x.holovko.ru/Xlib/contents.htm l

Hope someone finds them usefull...
Creating a window manager, is actually quiet fun, as long as you have others code to look at...

Re:X Programming In C

[AJWM]

the rest are fluff, imnsho.

Hardly. If you're doing Xlib programming (Vol 1), then you'll also want Vol 2 (Xlib Reference Manual). Granted, Vol 3 (X Users Guide) probably won't tell X programmers much they don't know, and if you're using one of the non- Xt-derived toolkits (GTK, Qt, etc) then the later volumes (4 & 5, Xt Programming and Reference Manuals respectively, and 6, Motif) aren't necessary -- unless you ever hope to figure out how some of the older code out there works.

Nobody uses XView (Vol 7) any more (do they?) and the X Window SysAdmin's Guide (Vol 8) is useful only to sysadmins of large X-based thin client installations (such as Largo City FL, perhaps?), but I wouldn't exactly call them "fluff".

(And yeah, I've got the whole set, including both "regular" and "Motif" editions of some, plus the R6 supplement, and the "Nutshell" volume -- which is actually pretty handy as a desk reference over the thicker volumes. But then I've been doing X Windows programming since late X10 days circa 1987.)

Re:X Programming In C

[starless]

> Nobody uses XView (Vol 7) any more (do they?)

I do!
A nice toolkit and free as well.

Re:X Programming In C

[Clith]

[URL-ized version of informative post]

I have the following links (I'm trying to write a window manager myself... :-)
I hope these are the ones you lost:

http://www.xfree86.org//4.3.0/manindex3.html
http://tronche.com/gui/x/icccm/
http://tronche.com/gui/x/xlib/ http://x.holovko.ru/Xlib/contents.html

Hope someone finds them usefull...
Creating a window manager, is actually quiet fun, as long as you have others code to look at...

Re:X Programming In C

[fuqqer]

Just what we need... Another window manager when we already have a good one!

Although, it is always nice to have some peaceful quiet fun, rather than those rowdy programmers writing operating systems. Plus, they never learn from looking at other operating systems code.

Re:X Programming In C

[AJWM]

Okay, so there's still one XView user out there ;-)

Seriously, I always liked OpenLook's look over Motif but found myself working in Motif shops. The Xol (OpenLook based on Xt) library was a nice compromise -- using it I once converted a 20,000 line Motif app to OpenLook in about a day, mostly converting a lot of Xm strings to their identical Xt equivalents and changing a few library calls (the result compiled to either Motif or OpenLook with a few #ifs and a link to the appropriate library).

Alas there don't seem to be any free Xol libraries around, not that I've looked very hard. Maybe I'll do my next project in XView just to annoy the GTK/Qt whippersnappers ;-)

Re:X Programming In C

[Mandrake]

However, all that is in volume 2 is man pages in printed format, for the most part. nothing available in that book (which I also own) that isn't easier to find using the command line.

Re:X Programming In C

[AJWM]

Easy to find if you know what you're looking for (ie, you know the function name, you just need to remind yourself of the type and order of the parameters).

Nothing beats browsing a book, though, to find functions that you didn't know existed but realize you can put to good use. (Sure, you can browse on-line too, but a book is more convenient for places like the bathroom...)

Re:X Programming In C

[Viol8]

Not all systems have the Xlib man pages installed by default. Certainly here none of our Solaris systems do not.
Also the appendices in the book are very useful.

Re:X Programming In C

[Viol8]

Why should XFree come with documentation about the API? Does linux come with a dummies guide to unix systems programming installed? No, you
have to go and buy a book or readup somewhere else. Same with X windows and given how complex the X API is
I can't see how you could expect otherwise.

Why would you want to use anything but Swing?

[Anonymous Coward]

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.

Re:Why would you want to use anything but Swing?

[Anonymous Coward]

Because SWT does everything that Swing does (except suck)

Re:Why would you want to use anything but Swing?

[Delirium Tremens]

> Why would you want to use anything but Swing?

Short Answer is: S.W.T.
Long Answer is: here.

Re:Why would you want to use anything but Swing?

[truth_revealed]

Why a native C/C++ GUI toolkit?

- can distribute a statically linked 2 meg executable - quick to install
- typically only 2 megs of resident RAM used by running program
- virtually zero startup time
- much more responsive GUI
- still runs well on hardware more than 4 years old

Why not Swing?

- don't want the 40 meg downloadable JRE footprint
- don't want Java version hell for your users/customers
- don't want the 40 Meg of resident RAM required by the smallest running Swing program
- requires the latest hardware for decent speed.

Re:Why would you want to use anything but Swing?

[coolfrood]

Not trying to troll here, but even with the latest and greatest Java (1.4), Swing is still extremely slow over X. Try using JBuilder (or any other Swing app for that matter) over X remotely. The way the response and refresh lags is just painful.

Re:Why would you want to use anything but Swing?

[bobbotron]

Just as a quick reply to everyone else in this thread, I just ran into the Zaval Ligh-Weight Visual Components Library the other day. It's a really optimized java based GUI library: those gripping about the slow swing library should check it out: it seems to have a lot of useful features, and is fast and small!

Re:Why would you want to use anything but Swing?

[WNight]

Because you have to program in Java.

With GTK or QT you can write wrappers for any language. Want GUI functionality from LISP, or Haskell, or Perl?

Java's not a bad language, for what it is, but anyone trapped into dealing with a single language is missing out.

Re:Why would you want to use anything but Swing?

[penguin7of9]

Well, let's see, why wouldn't you want to use Swing?

• Swing is a Java-only toolkit; people program in many other languages.
  
• Swing is a Sun-proprietary toolkit; there is no independent implementation, either commercial or free, and it isn't clear anybody will ever be able to create one.
  
• Java+Swing fails to have native look-and-feel on X11, it doesn't integrate well with desktops, it doesn't pick up themes or preferences, it doesn't let software get at even the most elementary information from the user environment, etc.
  

Java+Swing is a decent, popular cross-platform environment, albeit a Sun+proprietary one. And Swing is pretty general, complete, and easy to program in.

But Swing is certainly not a panacea for cross-platform software development, and it is at best a mediocre compromise for writing Linux desktop applications.

Re:Why would you want to use anything but Swing?

[Anonymous Coward]

Because I'm not writing the application in Java?

Note that Swing is pretty similar to many of the C++ libraries in terms of the interface, except that receiving events from Swing is a PITA because Java doesn't have first class methods or first class functions.

Java is still the language that explicitly avoids giving people powerful language features (macros, closures, a non-verbose syntax).

Re:Why would you want to use anything but Swing?

[cryptoluddite]

Why Swing?

- can distribute 100k dynamically linked code on web (WebStart; no install needed)
- typically only 1-2 megs RAM used for actual UI (Mac OS / shared VM)
- runs on all operating systems without recompile (compile once)
- much easier, much more powerful GUI
- huge class library

Why not Qt?

- don't want buffer overflows and crashes
- don't want to rewrite everytime APIs change
- don't want to reinvent the wheel to do double-buffering, gradients, anti-aliasing, etc.
- requires finding, linking other libraries to do any real application.

Re:Why would you want to use anything but Swing?

[p2sam]

GTK cannot be statically linked.

Re:Why would you want to use anything but Swing?

[da]

Er, and your point is?

Conclusions from the first article that the parent's Google search points to:

If you don't need cross-platform development and your target OS is supported (Windows, for example), you may consider SWT, especially if your customers have old, limited machines where Swing use can be prohibitive. For all other scenarios, Swing provides the conservative choice.

I don't know anything about SWT other than what I read in the article but you haven't sold it to me!

Re:Why would you want to use anything but Swing?

[d2003xx]

It's far faster, and only getting faster with each release

But it's still slower than native GUIs.. And swing apps take forever to launch, and eats tons of RAM...

Re:Why would you want to use anything but Swing?

[d2003xx]

- can distribute 100k dynamically linked code on web (WebStart; no install needed)

But it takes forever to start


- typically only 1-2 megs RAM used for actual UI (Mac OS / shared VM)

Actually at least 20MB for the whole program, on windows


- runs on all operating systems without recompile (compile once)

Yes if you don't use JIT, which compiles every time when you run the program.


- huge class library

Where's the html browser widget??

Re:Why would you want to use anything but Swing?

[cryptoluddite]

- can distribute 100k dynamically linked code on web (WebStart; no install needed)
But it takes forever to start

On Linux.

- typically only 1-2 megs RAM used for actual UI (Mac OS / shared VM)
Actually at least 20MB for the whole program, on windows

Windows sucks.

- runs on all operating systems without recompile (compile once)
Yes if you don't use JIT, which compiles every time when you run the program.

Equivalent to linking libc.so every run. Ooh, scary.

- huge class library
Where's the html browser widget??

new javax.swing.JEditorPane(documentURL);

For Pure Sadism -

[EnderWiggnz]

Try using KDevelop 1.2!!!!

yippeee!!!! wheeelah....

yeh baby!!!

Re:For Pure Sadism -

[arivanov]

Sadism or masohism? Sadism is if you apply it to someone and maso is if you selfapply it.Which one do you mean?

This Guy is heavily biased against QT

[Anonymous Coward]

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.

Re:This Guy is heavily biased against QT

[BiggerIsBetter]

That's a pretty lame reason for bias, when the stated title of the article is "GUI Toolkits for The X Window System".

Yeh, I like QT, but I like wxWindows, GTK+, Java, and lots of others too.

Re:This Guy is heavily biased against QT

[unoengborg]

And even that would not be a good reason for the bias, as there is an ongoing project to port qt3 to win32.

See http://kde-cygwin.sourceforge.net/qt3-win32/index. php

I have never tested it, as I live mostly in the Unix/Linux world, but the screen shots looks promising:

http://medlem.spray.se/larkang/qt3-win32/

I really don't see what Trolltech have done to deserve all this bad mouthing. They ship QT under GPL making it possible to use it for free software. They have also propriatory licenses for commersial development. Given that the speed of development and level of code reuse with QT is only rivaled by Java, he price for a commercial license is extremely low.

Hey, I think I spent more money on taxi to the airport when travelling between our offices in Malmo and Stockholm dureing a year. The price is also low compared to other tools of the trade for a professional software developer e.g. the Rational Rose.

It's true that Gtk is free for commercial use, but if I have to hire a developerone more month to iron out bugs in the windows version when developing a cross platform application I not only lose money in the form of salery to the programmer but I also lose time to market.

Somtimes free is too expensive. Even in the free software market, where the business model is based on supporting free applications rather than schrink wrapped software packages, this can bite you. If means that you have to spend more time with each support issue. To some extent this is good as you can charge your customer more money. But normally it would be better to be able to handle more customrs.

-1 Troll(tech)

[CausticWindow]

This article reads like a Qt flamefest.

I don't see how Qt's "business like homepage" should have anything to do with how good a toolkit Qt is. The "free for linux not for w32" is of course a valid point, but it's the only one.

Re:-1 Troll(tech)

[LizardKing]

This article reads like a Qt flamefest.

Certainly does. He also dislikes C, yet he programs using GTK+. I guess he must be a fan of gtkmm. Frankly, I get the impression that the articles author is a little bit inexperienced, and would be better off learning Java and its Swing API. That will give him a decent grounding in MVC architecture, while keeping him otherwise occupied so that he doesn't write any more articles :)

Chris

Re:-1 Troll(tech)

[Des Herriott]

Yep, the author obviously has some kind of beef with Qt.

"Commercial" and "proprietary" are not at all the same thing, but the author believes you need to pay to sell Qt applications. Wrong - you are permitted to sell GPL-licenced software.

The fact that the toolkit is large and takes a long time to compile (a few hours on a moderate-spec PC) is irrelevant. You don't need to recompile your toolkit every day, and you get binary Qt packages with most Linux distributions anyway.

"Business-oriented main website" is a non-argument, as you say.

"Main branch depending on one company" is a non-argument, since even if Trolltech folded tomorrow, a GPL-licenced Qt can be picked up by volunteers, just like any other free toolkit.

The namespace concern is the only minus point with any merit - on the other hand, I don't see Gtk+ using namespaces either, and that wasn't mentioned as a minus point, was it? (Yes, I know Gtk+ is written in C - but that doesn't alter the fact that it too does not use namespaces)

This article wasn't a summary, it was a soapbox rant.

Re:-1 Troll(tech)

[Xerithane]

I don't see how Qt's "business like homepage" should have anything to do with how good a toolkit Qt is.

Considering that Trolltech is a business, I think it does reflect the quality of Qt. If Trolltech was a business, and their website looked like half the other OSS projects out there, nobody would take them seriously.

The "free for linux not for w32" is of course a valid point, but it's the only one.

That isn't even a valid point. Qt 2.3 for Win32, free.

Re:-1 Troll(tech)

[nate1138]

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.

Re:-1 Troll(tech)

[n3bulous]

http://kdemyths.urbanlizard.com/viewMyth.php?mythI D=60

Re:-1 Troll(tech)

[n3bulous]

Bah. Not sure how that space got in there...

KDE MYTHS

Re:-1 Troll(tech)

[nate1138]

Very interesting. Thanks. Canopy's web site does not make this clear at all.

Re:-1 Troll(tech)

[Anonymous Coward]

I'm a gtk+/gnome fan, and I think QT definitely has a number of drawbacks, including its licensing. You're right, though- the author of this article makes uninformed and inflammatory remarks concerning QT and is quite unfair towards it, and some of his comments are such strange nitpicks I don't know what to think of the article.

Re:-1 Troll(tech)

[Pr0xY]

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

Re:-1 Troll(tech)

[i_really_dont_care]

"Commercial" and "proprietary" are not at all the same thing, but the author believes you need to pay to sell Qt applications. Wrong - you are permitted to sell GPL-licenced software.

Yeah right, good luck...So then why do you think QT sells you the right to use another license than the GPL?

Seriously, GUI toolkits are quite trivial things nowadays. There are alot of them, and most of them are just fine for usual tasks. Even if QT may have some slight advantages in one place or another, I seriously doubt this difference is worth thousands of dollars. Heck, even Lesstif is LGPL. Also, with GTK+ and wxWin finally catching up, I doubt that Trolltech would have that many customers if it weren't for KDE. And I dare to predict that the more popular Linux gets, the more apparent this problem will get, because people will be running KDE, but all commercial software will be based on GTK etc., destroying all the potential for this superior desktop...

Re:-1 Troll(tech)

[drewness]

The namespace concern is the only minus point with any merit - on the other hand, I don't see Gtk+ using namespaces either, and that wasn't mentioned as a minus point, was it? (Yes, I know Gtk+ is written in C - but that doesn't alter the fact that it too does not use namespaces)

But, GTKmm does use namespaces. It uses a lot more modern C++ features than QT does. To be fair though, I've not done more than read a tuturial, so it might not be all that hot for all I know.

Re:-1 Troll(tech)

[BraveLittleHamster]

The namespace concern is the only minus point with any merit ...

The lack of Qt namespaces is a style point that I agree with. TrollTech uses them in the places where namespace association is important (and convenient) for the end user. The various flags (Qt::AlignHCenter, etc.) and settings are wrapped up in a namespace, but class definitions and functions are kept seperate for good reason. Scopeless primitives are much easier on programmer eyes and fingers as type information isn't constantly engulfed in unnecessary ::operators.

QListView::iterator is easier to type ( and read ) than Qt::ListView::Iterator.

It is very easy to accumulate hundreds or thousands or references to Qt primitives in the course of developing even a small application. All those extra ::'s are decidedly inconvenient. You can always go the route of
using namespace Qt
but then you are back to needing some sort of prefix for Qt primitives that makes them easily stand out. All in all, namespaces are really only necessary in situations like that of the c++ stl where containers like vector and list have such generic names that a system for preventing users from creating name conflicts must be present.

OpenGl is an example of a near perfect api in my opinion.

Re:-1 Troll(tech)

[infiniti99]

The "free for linux not for w32" is of course a valid point

I don't even think this is a valid point. What if there wasn't a Qt/Win32 port at all? I don't see how the existence of a win32 port makes the X11 version any less free. And it's not like Windows portability makes or breaks a toolkit. Portability wasn't even the focus of his article.

You know, there was a time when gtk didn't have a win32 port. So some good folks ported the x11 version. In fact, some folks are doing that now for Qt! Isn't freedom wonderful? Qt/X11 is GPL. Just because Trolltech has an uber-cool win32 port of their own doesn't change anything about the freedom of Qt.

Re:-1 Troll(tech)

[mnmn]

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.

Re:-1 Troll(tech)

[Anonymous Coward]

gtkmm does use namespaces, PLease read the article again. Don't compare a c api to a c++ api....

Re:FOX Toolkit?

[Anonymous Coward]

Let's just hope the review is as fair and balanced as FOX news.

writing graphics software

[dollargonzo]

one of the biggest problems in writing a RAD graphics software is that lots of users want it to interface with a lot of different toolkits, such as motif, qt, gtk, tk, xt, etc. obviously, it would be nice if they all just chose one, but that will not happen anytime soon. now, we[the company in mind] are thinking of writing our own low level toolkit (since the software currently doesn't have its own widgets). this is basically how new toolkits come into existence and the user base is forced to choose at yet another fork in the road. *sigh*

Re:writing graphics software

[Christianfreak]

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.

Re:writing graphics software

[dollargonzo]

wxWindows is just another toolkit. it's no different than the others. if, on *nix, someone wants the software to interface with Qt, i need to write a wrapper; same for every other toolkit. the problem is not ease of use here, it's a matter of using one toolkit over another. by suggesting a toolkit, you clearly misunderstand the problem. also, linux and windows are by far the minority of the operating systems the sofware is deployed on, and gtk isn't so hot on other unices, as it is much more difficult to get systems up to date and run gtk. as i said, it is far easier to make our own widgets than to use any given toolkit. that way, no one can complain, and can imbed the graphics into any application they want.

Exactly

[Anonymous Coward]

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.

Re:Exactly

[Anonymous Coward]

Maybe you should investigate Qt and work out how to use static linking..

Re:Exactly

[RevAaron]

I too need to write GUI apps that just work on a number of platforms- Mac OS X, Mac OS Classic, Windows, Linux, IRIX and Solaris, and have it work with a simple ./configure; make.

Luckily, I don't have to use Xlib, although the display system for X11 probably uses Xlib. I use Squeak Smalltalk, and can distribute my application with the virtual machine for the specific platform, or as Unix source for somebody to compile if they're on a more obscure platform. This can be easily included with my tarball- no need to download stuff seperately. It is also a small addition to my own code, so it's not like you're adding a big download or hassle.

GTK+, Qt and the desktop libraries that accompany them, on the otherhand, *are* a big hassle. Most Linux systems have a version (or two!) of one or both of those libraries, but often enough when deploying, you still have to have them install the version you wrote your app against- and you better believe it's not quick and easy!

Re:Exactly

[FooBarWidget]

"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."

You mean ./configure && make install won't work out-of-the-box for some reason?

Re:Exactly

[AvitarX]

Why don't you do what normal software distributers do?

Include GTK 1.2 and then have your instal check if it is needed, if it is install it.

Like when I buy a game I get DirectX with it. I guess installing that library is gonna kill me.

There is no reason you can't include GTK 1.2 since it is Open source.

Of course the bugginess is another issue, and obviously if that is the case you cannot use it, but I see no reason you can't make it easy to install by modifying your make script.

Even the Gimp was an easy install in Windows once I found all the packages, but someone could have bundled them together easy enough.

Re:Exactly

[Anonymous Coward]

You mean ./configure && make install won't work out-of-the-box for some reason?

Unfortunately, some of these toolkits(Qt for instance) have all sorts of bizarre dependencies which cause one to search all over the internet to find them, and once found, one must search all over the internet again to find the dependencies for that dependency, ad infinitum (so it seems). And when you do finally install all dependant files, you quickly discover that the retarded package manager (rpm) will tell you that you don't have the files that you know you have (you've just installed them!!) because if it's not in the rpm database, it doesn't exist...so if you've downloaded and installed files the tradional way with ./configure && make && make install, well...you are out of luck. Sometimes the only option is to install an entirely new version of the operating system which is not an option for most people.
Also, Qt is so ingrained into the window manager system, that often, you must reinstall the entire window manager in order to install Qt.
And when you go to the kde website to download, there is never a convenient single download, you have to go all over the place and guess which files you have to download.
So, the problem is actually one of not making a toolkit user-friendly to download, rpm being not at all "intelligent" (or is that the creators/designers of rpm?), and having a toolkit to intertwined with its windowing environment.

Re:Exactly

[Anonymous Coward]

Squeak is great. If you like obtuse, arcane user interfaces (OAUI's).

Re:Exactly

[Permission Denied]

Include GTK 1.2 and then have your install check if it is needed, if it is install it.

Yes...and also include Pango, gettext, GNU Make, pkg-config, glib, ATK, GNU iconv, libjpeg, libtiff and libpng. Then you can figure out via a very simple configure script which ones are installed and which ones need to be installed. And none of those nine dependencies or any of their dependencies will have a bug in their autoconf scripts that prevents them from compiling via a simple ./configure && make on AIX or HP/UX or Irix. Of course, you also include the dependencies for each of the above nine dependencies, so you end up having perhaps fifteen or twenty libraries that you distribute, compile and statically link to your little server program so it can show a configuration dialog box.

While you're at it, you might as well include util-Linux (or whatever) for the build process so you don't have to deal with a funny version of sed (not a big deal since your software already uses non-standard gmake extensions, requiring it to build with only GNU Make), and you might as well include GNU awk if you require GNU sed. Of course, you'll need to include GNU bash since somewhere in one of those dependencies, some programmer used a non-standard bash extension rather than plain Bourne in his autoconf script.

And, of course, you have to deal with GNU C extensions in those dependencies such as non-standard variable-argument macros or the "typeof" operator, or zero-length arrays and you don't want to force your dependency developers to have to deal with HP's buggy compiler. So you might as well include GCC and its dependencies such as binutils. While you're at it, go ahead and include glibc so you don't have to modify some dependency to use pthreads correctly rather than relying upon some bug or inadvertantly exposed interface in glibc.

By this time, you've surely run into some network library that looks for "struct udp" in <linux/udp.h> or forgets to include sys/types.h before unistd.h. You might as well include a copy of the Linux kernel, since all the above depencies are known to work well on Linux (after all, that's almost exclusively the system used for their development).

Hell, you might as well just give your clients a Redhat CD. Screw those people who choose to use something else.

Re:Exactly

[AvitarX]

WOW!

I didnt realize things were so bad.

I really have a better picture of why half the apps I use look like ass (they do work well though).

Thank you for putting it to me so clearly.

I probably shouldn't have been so rud in my initial post and appologize.

Re:Exactly

[Permission Denied]

Hey, no problem. I am of course exaggerating. GTK 1.2 is not that bad, but GTK 2 is near-impossible to get working on non-Linux/BSD systems. It's nothing fundamentally wrong with GTK, but any huge piece of software that uses all the latest gizmos and APIs and has lots of dependencies from unrelated parties will likely be less portable. Sometimes it saves man-hours to simply write some bogus thing directly in XLib rather than figuring out how to get some library to compile on some esoteric *nix (and then duplicating that for each of your users). Xlib really isn't so bad - it's actually quite nice (compared to, say, Platform SDK), but it's very low-level so you have to write all your own widgets which, for most of us, will look like ass. But writing your own widgets from scratch is fun (at least it's fun the first time you do it).

Perhaps fltk could be useful in these circumstances: it looks like it can compile with just X11, no external libraries. Never really played with it but it looks very nice (especially since it's designed to make static linking feasible).

Re:Exactly

[RevAaron]

Out of the box, Squeak has the potential to be really ugly; but with recent changes (in the last year or two), it's cleaned up quite a bit. For a while, there's been the capability to load IceWM themes... C'mon- it isn't that ugly.

Why the Qt bashing?

[arvindn]

Look at the last paragraph of the article:

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.

Re:Why the Qt bashing?

[Mandrake]

well, to be fair, moc really is a pain in the behind. the fact that it doesn't let you use any c preprocessor macros for things like header include files make it difficult to support cross compilation for a wide variety of platforms without doing additional non-cpp (auto-tools style) preprocessing, which means you have to forego their make-building utilities... which means that you lose their ease of cross-platform compiling. this is particularly apparent (at least to me) when trying to build a dual mode Qt and Qt/E application, or at least it was when the zaurus first came out.

Re:Why the Qt bashing?

[Anonymous Coward]

Uh? moc doesn't limit the use of cpp macros in any way. Except of course, defining Q_OBJECT, SIGNAL and SLOT macros messes your code somehow.

moc is simply transparent, 99.99% of the time.
The other 0.01% is trivial (you need to #include the moc files, or something similar).

Please give an example, or I will just decide you are full of crap.

Re:Why the Qt bashing?

[dreamchaser]

Why is it bashing to point out that QT is not free software? If people are looking for a free cross platform toolkit, QT isn't it.

Re:Why the Qt bashing?

[Anonymous Coward]

Last I checked, Qt had GPLd versions for X11, OS/X and win32 (win32 is not mature).

So, you are wrong. Qt *is* free and Qt *is* cross platform, even if you decided to ignore the win32 GPL version.

Now, crawl back under a rock, and start posting about things you are familiar with, like navel lint.

Re:Why the Qt bashing?

[Carewolf]

People loves to hate the top-dog.

It is just a sign that KDE has established itself firmly as top-dog, and people no longer thinks the GNOME revolution is just around the corner anymore.

Re:Why the Qt bashing?

[fault0]

> the fact that it doesn't let you use any c preprocessor macros for things like header include files make it difficult to support cross compilation for a wide variety of platforms without doing additional non-cpp

Huh? Qt lets you use C preprocessor macros in header include files.

Re:Why the Qt bashing?

[fault0]

The article was about X Window Toolkits.. What does X11 have to do with win32 or other systems?

Re:Why the Qt bashing?

[dreamchaser]

You have a good point there. I won't bother replying to the AC who told me to crawl back under the rock, though. At least you had an intelligent point to make.

Re:Why the Qt bashing?

[ShieldW0lf]

Last I checked, Qt had GPLd versions for X11, OS/X and win32 (win32 is not mature).

So, you are wrong. Qt *is* free and Qt *is* cross platform, even if you decided to ignore the win32 GPL version.

Now, crawl back under a rock, and start posting about things you are familiar with, like navel lint.

The GPL version of Win32 QT is out of date, and is not being further developed.

With the market share that Win32 has, support for it is an essential component of a portable toolkit if you are developing for the public.

I suspect that the ONLY reason that many developers would choose a toolkit is to achieve portability to platforms beyond Win32, and if they had to choose between making their program available to Win32 and making it available to everyone else, they'd choose Win32.

In this VERY typical case, if you want to build free software AND you want to see your mom use it, GPL'd QT is not an option.

Re:Why the Qt bashing?

[SpinyNorman]

Huh? If you want GPL use the GPL'd Qt. If you want to write a closed source app. use the commercial version.

Seems simple enough.

Re:Why the Qt bashing?

[Anonymous Coward]

And the AC that told you to crawl under your rock also seems to have had one. You were WROOOOOOOOOOOOOONG. Materially, factually, obviously WROOOOOOOOOOOOONG.

Have a nice day.

Re:Why the Qt bashing?

[penguin7of9]

There is a disturbing trend of recent articles that engage in Qt/KDE bashing.

When people say that they think a dual-licensed GUI toolkit is bad for the goals that open source software is trying to achieve, or when they say that a C++-based toolkit won't do for them, that's not "bashing", that's an honest and straightforward assessment of their own needs.

If the KDE project doesn't want to listen to the community or is convinced that these objections don't matter, that's fine: respond in a calm and rational manner or be quiet. But accusing people of "bashing" because they disagree with you only makes KDE supporters look irrational. And KDE already has a big credibility gap on licenses because of the original QPL/GPL disaster. Maybe you should actually start listening.

Re:Why the Qt bashing?

[dreamchaser]

Which I freely admit, we are all wrong from time to time. That doesn't excuse childish flaming...oh wait....this is slashdot..nevermind...

Re:Why the Qt bashing?

[Anonymous Coward]

The level of ignorance in these replies is astonishing. You are probably confusing the non-commercial (not GPL) Qt 2 for win32 from TT with the GPLd Qt for win32, which is not from TT, and is indeed not mature.

Read, and learn:

http://kde-cygwin.sourceforge.net/qt3-win32/

And no, this is not Qt/X11 for win32, but a native Qt/X11 win32 port.

Re:Why the Qt bashing?

[Anonymous Coward]

Uh, you didn't admit it. At least not until it was rubbed on your face twice. If you are not gonna be gracious, at least be gracious about not being gracious!

Re:Why the Qt bashing?

[Mandrake]

well you're an anonymous coward so that says something about the 'full of crap' bit itself ;)

Here's an example however:

#ifdef QPE
#include <qpe/filemanager.h>
#include <qpe/fileselector.h>
#endif

No problem yet, until you try to do something in your object definition like...

#ifdef QPE
void openDoc(const DocLnk &doc);
void hideBrowser(void);
#endif

private:
QString filename;
#ifdef QPE
FileSelector *fs;
#endif

The problem is EXACTLY that it ignores these things. it ends up building source files that choke because in moc's auto-built sourcefiles it has references to things that don't exist anymore if you're not building for qpe. all because you want to do something simple like use the file selectors that come with qpe instead of rolling your own, so your app looks integrated into the system instead of like bits are tacked on.

apologies for the lack of indentation at all, because slash forms reject nbsp apparently. oh well.

Re:Why the Qt bashing?

[ShieldW0lf]

There is no suitable non-commercial version of QT available. There is no suitable GPLd version of QT available. The level of ignorance in my reply is not available.

The existance of incomplete code on a sourceforge project bears NO relevance for someone deciding upon a toolkit for free development, because it DOESNT WORK.

Your awareness of a non-functional sourceforge project doesn't make us ignorant, Trolling Coward. Who gives a shit? Likely, I never came across it when researching toolkits because no one can use it to build anything.

I'll stick with wxWindows, thanks.

Re:Why the Qt bashing?

[Mandrake]

see my other reply.

And I don't think qt is bad, honestly, regardless of the immediate troll-like backlash I got (not you, but the other person) - but I do think that moc is a pain in the butt for its total ignorance of preprocessor macros.

Re:Why the Qt bashing?

[iamnotaclown]

Qt's biggest weaknesses are its relic called "MOC" and its business orientation.

There is a disturbing trend of recent articles that engage in Qt/KDE bashing.

Agreed. Vague cricisism of MOC sounds more like parroting the GTK+ party line than analysis. MOC is a clean, simple way to add message passing to C++ without sacrificing readability. Those of us who have been through the hell that is MFC know that trying to bitch-slap C++ into doing things it wasn't designed for using macros does not a clean interface make.

Bashing QT for not giving away free Windows support is hardly a valid point. QT wouldn't exist if they couldn't sell their own software. MSVC isn't exactly free, either. Sounds to me like the author is annoyed that he can't find QT/Windows on Kazaa.

The author of the featured article admits to being a CS student who dabbles in UI projects in his spare time. Grow up, kid. Real programmers use the right tool for the right job, not the one with the loudest fan base.

Re:Why the Qt bashing?

[BitwizeGHC]

The author of the featured article admits to being a CS student who dabbles in UI projects in his spare time. Grow up, kid. Real programmers use the right tool for the right job, not the one with the loudest fan base.

Really. Then how did Java and VB get to so widely used?

Re:Why the Qt bashing?

[Anonymous Coward]

Properly written java looks nearly identical to properly written C++. Java seems to truly be write once, compile anywhere. They seem to have limited the language to prevent some of the "bad" things that C++ allows. And, Sun seems to have done a really good job of marketing java.

VB seems to be used by bad hacks who claim to be software engineers.

Re:Why the Qt bashing?

[Stele]

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.

Re:Why the Qt bashing?

[rubypossum]

There is a disturbing trend of recent articles that engage in Qt/KDE bashing. If you were a developer and there were three different options two were free and one had the potential of costing your company $1,500 which would you choose? He makes the argument that wxWindows/GTK+ have everything that QT has but have truly free licenses. This isn't bashing... this is common sense. There will be an almost constant time in developing the GUI for an application with these three toolkits. Why not choose one that you know you won't have to pay $1,500 to compile a Windows version for? A free version of QT for Windows is available but it is expressly for non-commercial use. To quote the Trolltech sight: "Private users may use the Qt non-commercial edition in a non-commercial setting to produce non-commercial applications. More details can be found in the Qt Non Commercial license." http://www.trolltech.com/download/qt/noncomm.html This means you must pay to sell a Windows version. So not using QT just makes sense.

Re:Why the Qt bashing?

[Harry8]

The article was about X Window Toolkits.. What does X11 have to do with win32 or other systems?
I offer this in the correct spirit, not as flame.
In choosing a Window Toolkit for X Programming, being able to port your app with the minimum of fuss to alternative OSs is a consideration for some programmers. Others want their app to run only on UNIX like OSs and can ignore this entirely. Horses for courses.

Re:Why the Qt bashing?

[Anonymous Coward]

... that is, however, assuming the toolkits in question are about as good in regards to design, features, cross-platformness and such important features. Based on experiences I have heard, Qt is superior in most of these features (followed by GTK+, but with big margin).

So basically you are wrong; it is a blatant bashing by an ignorant novice CS student who has no idea what a good design is, but has read enough of QT-bashing blogs to have formed a biased opinion.

Re:Why the Qt bashing?

[be-fan]

Qt/X11 is Free Software. In fact, its freer (according to the FSF) than GTK+, which uses the *Lesser* GPL.

Re:Why the Qt bashing?

[be-fan]

When people say that they think a dual-licensed GUI toolkit is bad for the goals that open source software is trying to achieve
>>>>>>>>>
Whoa. Qt/X11 is *GPL*. What more do you want? LGPL'ing it will only be even further from the goals of the FSF. Its called the LesserGPL for a reason!

, or when they say that a C++-based toolkit won't do for them, that's not "bashing", that's an honest and straightforward assessment of their own needs.
>>>>>>>>>
Its also a rather suspect claim. There are very few reasons not to use C++ for GUI toolkits these days. In fact, most popular GUI toolkits (MFC, WTL, Qt, WxWindows, Fltk) on X11 are C++. The only ones that aren't are Motif (Lesstif) and GTK+.

wxwindows - wxpython

[nuggz]

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.

Re:wxwindows - wxpython

[Christianfreak]

*not a Python bash I like it to* ... if you like Perl there's also WxPerl which is quickly becoming complete.

Re:wxwindows - wxpython

[khanyisa]

Why not for commercial apps? We write commercial apps using wxWindows, works great.

Re:FOX Toolkit?

[1nihilist1]

Ceci ne pas un sig. -- ?

Umm.. that should be "Ceci n'est pas une sig."
Although I don't think sig really works in french although it is short for signature, which works in french.

Whatever, maybe you were trying to be funny -- is so I am sorry for not catching it.

Toolkits do sacrifice flexibility

[r6144]

If you are developing a cross-platform high-level GUI application, just use toolkits. You don't need the flexibility of Xlib.

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.

Need monolithic executables

[Anonymous Coward]

I'd be nice to be able to static link into
one giant executable. I hate having the
incompatible libraries problem. It's like
DLL hell in windows. It'd be nice to have
a full featured GUI library (and other tools)
that can create one big executable file.
GTK programs require a DLL in windows.
WxWindows programs require GTK libraries on
Linux.

Re:Need monolithic executables

[Minna Kirai]

The FLTK library mentioned is intended to be statically linked into applications.

Re:Need monolithic executables

[syrja]

Short answer: Try FLTK. Works fine either statically or dynamically linked.

Re:Need monolithic executables

[Anonymous Coward]

interesting? come on... this is pure troll
(not a bad one if i dont say so myself)

Re:Need monolithic executables

[Anonymous Coward]

wxWindows does not _require_ GTK. There are several ports, including for Xll and Motif.

Re:Need monolithic executables

[cowbutt]

If you install the static versions of the libraries you use, then you can link statically:

$ gcc -L/usr/X11R6/lib -L /usr/lib/gcc-lib/i386-redhat-linux/3.2/ -static -o hewx ../source/he.o ../source/hebuffer.o ../source/heexpr.o ../source/hemisc.o ../source/heobject.o ../source/heparse.o ../source/heres.o ../source/herun.o ../source/heset.o ../source/stringfn.o hewx.o hewxwin.o hejpeg.o hepath.o hesound.o hevideo.o -lwx_gtk-2.4 -lgtk -lgdk -lpthread -lmikmod -lstdc++ -lsupc++ -lglib -lgthread -lX11 -lm -ljpeg -lgmodule -lXext -lXi -ldl

$ ldd ./hewx not a dynamic executable

$ ls -Al hewx -rwxr-xr-x 1 alex builders 5489167 Aug 12 17:09 hewx

$ mv hewx hewx.static

$ make

gcc -lwx_gtk-2.4 -lgtk -lgdk -lpthread -lmikmod -o hewx ../source/he.o ../source/hebuffer.o ../source/heexpr.o ../source/hemisc.o ../source/heobject.o ../source/heparse.o ../source/heres.o ../source/herun.o ../source/heset.o ../source/stringfn.o hewx.o hewxwin.o hejpeg.o hepath.o hesound.o hevideo.o -lm

$ ldd ./hewx

libwx_gtk-2.4.so.0 => /usr/lib/libwx_gtk-2.4.so.0 (0x4002f000) libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x404c7000) libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x40621000) libpthread.so.0 => /lib/libpthread.so.0 (0x4065a000) libmikmod.so.2 => /usr/lib/libmikmod.so.2 (0x406ab000) libm.so.6 => /lib/libm.so.6 (0x406ea000) libc.so.6 => /lib/libc.so.6 (0x4070b000) libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40836000) libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x408e8000) libgthread-1.2.so.0 => /usr/lib/libgthread-1.2.so.0 (0x408eb000) libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x408ee000) libdl.so.2 => /lib/libdl.so.2 (0x40914000) libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x40917000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40920000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4092e000) libpng.so.3 => /usr/lib/libpng.so.3 (0x40a0d000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40a31000) libtiff.so.3 => /usr/lib/libtiff.so.3 (0x40a4f000) libz.so.1 => /usr/lib/libz.so.1 (0x40a91000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40aa0000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

$ ls -Al ./hewx

-rwxr-xr-x 1 alex builders 332859 Aug 12 17:11 ./hewx

$ strip hewx

$ ls -Al hewx

-rwxr-xr-x 1 alex builders 194980 Aug 12 17:12 hewx

Be careful what you wish for though - look at the ~28x size increase of the binary though. Now imagine that for all the graphical applications on your system (not to mention the hassles with security updates, as witnessed when problems were found with zlib).

--

Re:Need monolithic executables

[suchenwi]

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/

Re:Need monolithic executables

[hak hak]

Be careful what you wish for though - look at the ~28x size increase of the binary though. Now imagine that for all the graphical applications on your system (not to mention the hassles with security updates, as witnessed when problems were found with zlib).

Yes, and not only that: if you have multiple programs using the same toolkit, the OS can't keep one copy of it in the disk cache and use it for each application, which results in either longer startup times (reading from disk) or more memory taken up. If you have only one program that uses a particular library, it is better to link statically, as this saves some time in the dynamic linker.

Documentation

[lunenburg]

For me, it came down to documentation. I have a moderately complicated GUI Perl app (Perl because it was the language I was most familiar with). I looked into various toolkits, like wxPerl, GTK/Perl, QT/Perl, but ended up using good ol' reliable Perl/Tk.

The big advantage with picking up Perl/Tk was that the O'Reilly books were extremely informative - good examples on each widget, how they interoperate, how to use them, and larger program examples. The documentation for the other toolkits I considered basically consisted of "look at the arguments this C++ function takes, and use it," which didn't make for an easy time picking things up (wxPerl was the worst in that regard). While an experienced C++ programmer might not have a hard time with that, it was way over my head.

As a result, though, I have a decent app that runs on X11 and Win32. With the great PAR archiver, I can even package the app up in a nice bundle.

Good times.

Re:Documentation

[Dan667]

I have built the same type of GUI's with Perl/Tk, but it suffers from being slow, so I am switching to a pre-compiled library, QT

Re:Documentation

[DavidNWelton]

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/

Re:Documentation

[Anonymous Coward]

Perl is a terrible language for writing GUI code, which is why the mainstream GUI toolkits support for Perl is spotty at best. For scripted GUIs, I'd take Python any day. Cleaner syntax, and better GUI support (good support for all of Swing, Qt, Gtk, Tk, WxWindows)

I've used Tk/Perl before too, and it worked OK. But the toolkit has a dated look and feel, and is largely unused. Considering the fact that Perl doesn't ship with the Tk bindings by default, and they are a large add-on package to ask users to download, I'd probably use Gtk instead, if I had to use Perl. BTW, the book IMO is largely a waste of money, and for the most part repeats what is already in the Perl-Tk documentation.

Missed the best

[norwoodites]

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.

Re:Missed the best

[roard]

I agree, it's quite shameful that he didn't even dared to mention it.

GNUstep is a true object oriented framework, running on Linux and other Unices, and there is even a port for Windows in early stage. It's an OpenStep implementation, as MacOS X's Cocoa, thus you could port GNUstep applications on MacOS X and MacOS X application on GNUstep very easily. GNUstep also has great RAD tools like Gorm, modeled after NeXT's InterfaceBuilder.

GNUstep supports distributed objects out of the box, has a great database library (you just deal with objects, define a link between thoses objects and your database's model, and hop, no need to SQL), support scripting very easily, uses the PostScript imaging model (no need to maintain two versions of your code for display and printing), etc.

A good example of a GNUstep application compiling both on MacOSX and GNUstep is GNUMail, available on http://www.collaboration-world.com/gnumail ...

I urge people to check http://www.gnustep.org website :-)

You could find informations and articles about GNUstep on http://www.roard.com/docs , there is also the gnustep's wiki (http://wiki.gnustep.org), a good GNUstep's site for news on http://www.gnustep.us and a great guide for installing GNUstep (http://gnustep.made-it.com)

It's really a shame that so few people contribute to this great project...

Re:Missed the best

[roard]

I should also add that it will be *really* great if more people sign the petition to ask Sun to release the LighHouse Design applications ! the petition is here : http://www.petitiononline.com/laafs/petition.html Sun doesn't use thoses software at all, yet some are really great (for example, Quantrix, a multidimensionnal spreadshit, or VarioBuilder, a tool to create small database-based applications like MSAccess).

If Sun choose to release some of theses apps, it would be possible to port them on GNUstep and MacOSX !

So please, sign the petition !

Re:Missed the best

[UnuMondo]

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.

Re:Missed the best

[Anonymous Coward]

How do the text components in GnuStep compare to Cocoa?

I looked at a bunch of crossplatform toolkits, but the only ones with highly customizable text objects were Tk and Swing, and for my purposes neither comes close to Cocoa. And Cocoa's also stronger on multimedia (AudioUnits, etc), which I also needed, so now my nifty idea is a Mac application.

I'm hoping that a port to GnuStep won't be too heinous.

Re:Missed the best

[UnuMondo]

You'll have to be a bit more specific about what you need. Now, since GNUstep is fully object-oriented, you can always subclass existing text classes if you need something more. I invite you to the #gnustep IRC channel on Freenet if you have any questions about the API.

Re:Missed the best

[ipjohnson]

Its "a multidimensionnal spreadshit" I'm not sure if I want to sign a petition asking for sun to spread more shit ....

Re:Missed the best

[bnenning]

It's really a shame that so few people contribute to this great project...

Agreed. The API is extremely powerful and productive, and GNUstep has excellent compatibility with Cocoa/OpenStep. Maybe it's because people don't want to learn Objective-C ("nobody uses it and it has weird brackets"), which is a foolish attitude that I once had. Mostly I think it just needs more apps that show off its power.

Re:Missed the best

[Anonymous Coward]

Dude, learn to use the tag.

Re:Missed the best

[Anonymous Coward]

Thanks. My main requirement for text is the attributed strings, with attributes I can define myself.

FLTK licensing is *incorrect*

[Junks Jerzey]

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.

Re:FLTK licensing is *incorrect*

[cowbutt]

The author claims it is not free software.

Bzzt. The author claims that the predecessor to FLTK, XForms, isn't free software - and it isn't.

--

Re:FLTK licensing is *incorrect*

[Anonymous Coward]

Bzzt. XForms has been LGPL for almost 18 months.

http://bob.usuf2.usuhs.mil/mailserv/list-archive s/ xforms-archive.2002/0144.html

Re:FLTK licensing is *incorrect*

[Anonymous Coward]

Bzzt! Wrong!

I don't have a comment about the topic. I just enjoy watching you geeks shoot each other down by shooting "bzzt! wrong!" all the time. Do you live in some kind of fantasy game show world?

Re:FLTK licensing is *incorrect*

[Anonymous Coward]

Bzzt. It's just "Bzzt." not "bzzt! wrong!" , nincompoop.

Re:FLTK licensing is *incorrect*

[cowbutt]

Oops.

The newest XForms release I could find on the official website was 0.89, and the Changelog listed no change in license. Not surprising as it didn't happen until 0.9999. ;-)

--

Program in what you like

[ChiefArcher]

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

Re:Program in what you like

[panda]

When I programmed for the companies I worked for, I generally didn't program with what I liked, I programmed with what I was told to use by my boss.

Re:Canopy Group Owns Trolltech/SCO

[Zing]

"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)

What, no {Mo,Less}tif?

[AJWM]

Yeah, I RTFA and know he disses them with "too hard, too much like Xlib" (actually they're built on Xt, which is built on top of Xlib).

But anybody who thinks Xt is "too hard" probably is out of their depth programming GUIs anyway. (Now, if you think it's ugly, that's a whole 'nother discussion...) And nothing else gives you that level of flexibility and control. (Well, nothing else sane -- if you want to code direct to the X protocol, go right ahead...)

Re:What, no {Mo,Less}tif?

[muonzoo]

Took the words right out of my mouth. I've be writting GUIs and graphics applications for X since X11R3. Xlib has a bit of a curve to it, but if you have any background at all in computer science and graphics, it isn't too hard to understand the abstractions. The X Window System has a long and interesting history.

Xlib still has a lot going for it, espcially in terms of availability on the various UNIX variants out there and one of it's often overlooked features, especially by younger less experienced developers: network portability. This feature is absolutely wonderful inside a corporate or research environment where your workstation isn't necessarily where you run your code and/or do your work.

Xlib + Xt + Motif + MotifTools (or whatever they are called today) is still a viable, useful toolchain for developing applications. Canada's latest civilian Air Traffic Control Enroute system (CAATS) uses Xlib + Xt + Motif for it's extremely customized UI. (It's not for the faint of heart -- no help ballons there). The Canadian Military also adopted a system based on the same underlying technology (from the same vendor) for it's ATC enroute and local control.

As always, the right tool for the right job, but also, the right developer for the right job helps a lot too. You wouldn't let a kid loose with a jackhammer, so why let an inexperienced software developer loose with Xlib + Xt + Motif? :-)

Re:Linux 2.6

[Anonymous Coward]

make qtconfig -- QT interface
make gconfig --- GTK interface

Missed the most promising one: Java/SWT

[Anonymous Coward]

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...)

Re:Missed the most promising one: Java/SWT

[javatips]

The fact that Netbean is very slow is not due to Swing.

Just look at JBuilder, it load as fast and is as responseive as Eclipse. JBuilder is using Swing.

You should never compare two different toolkit by just comparing just one application for each toolkit.

Also SWT as some portability problems. They get addressed pretty fast, but is not as portable as Swing is.

Re:Missed the most promising one: Java/SWT

[ajm]

IntelliJ/IDEA proves you don't need SWT for Java GUI speed. Just give it a go. Very fast, yet written in Swing. The latest NetBeans is also no slouch.

Re:Missed the most promising one: Java/SWT

[radish]

Likewise IntelliJ IDEA - a stunningly good Java IDE. It's interface is Swing, and it's generally pretty good. There are times when it gets a little unresponsive, but it's usually the underlying processing it's doing causing the slowdown, not the GUI. Their custom look & feel is also nice eye candy, with advanced features like translucent windows.

Re:Missed the most promising one: Java/SWT

[joss]

> Did I mention coding in Java is much easier than fighting with ancient macros in C or C++?

Mustn't feed the troll, mustn't feed the troll... arrgh... cannot resist, if only java did have macro's there would be a decent way of dealing with version hell, if only it had templates we wouldn't need a ton of hideous upcasts, oh well nevermind, java's lack of features is always going to please some.

Re:Missed the most promising one: Java/SWT

[Space cowboy]

Hmm. JBuilder isn't that good with medium-sized projects. We have 3 developers (all enterprise) working with a 3500-ish java-files project. Each machine has 1.5Gb ram, and a 2Ghz processor. The JVM in jbuilder just gets tied up in knots sometimes - you move the mouse, it lags behind; hit the 'close-window' and it can take literally minutes for the VM to catch up; etc.

Sometimes it's great. Certainly going to the 'about' tab and forcing a garbage collection helps, but Jbuilder could certainly improve....

Whether that's JBuilder's problem, or Swing's problem, is of course hard to determine :-)

Simon

Re:Missed the most promising one: Java/SWT

[Anonymous Coward]

Mustn't feed the troll, mustn't feed the troll... arrgh... cannot resist.

Version hell? Not really. Nothing is perfect, and I'm sure you can name a specific example where things got ugly but Java does the best job of supporting "requires version XXX or better" that I have ever seen. Ancient java code (compiled with ancient compilers) runs fine (and can be called by shiny new code) on the latest and greatest JVM. If you want to compile it with a new compiler, you will probably get some warnings that boil down to "Man this is old code" The compile will work and the result will run.

This is version hell?

Re:Missed the most promising one: Java/SWT

[javatips]

You can surely increase the maximum heap size for the VM in jbuilder_home/bin/jbuilder.config.

Change "vmparam -Xmx128m" to "vmparam -Xmx512m" or more if you want.

That should help a bit.

Have one project with >3500 files seems a little weird to me, you could probably split that in many subprojects which would make more sense, especially if you use build scripts.

I've work on large project too with JBuilder, be we put each component/module in it's own directory structure with their own build script (Ant). Then have a build script at the root of the project that will orchestrate building of each component/module based on their dependencies.

Then we have one JBuilder project for each component/module.

That allow for faster builds and we never hit a performance snag in Jbuilder.

Re:Missed the most promising one: Java/SWT

[penguin7of9]

Did I mention coding in Java is much easier than fighting with ancient macros in C or C++?

That depends on the applications. Try writing numerical code or access shared memory from Java. I think Java just got feature-frozen too early, and what we have ended up with is a decent language, but not one that will replace C++.

I think C# has a better chance of taking over from C++: C# is mostly like Java but adds many of the features necessary for a general purpose language. If worries about C#'s ownership can be resolved, I think it may end up being more successful than Java, both on commercial and on open platforms.

Re:Missed the most promising one: Java/SWT

[JanneM]

Wow, it sounds great!

Now, can you just please post a link to C/C++ or Perl bindings for the toolkit? Thanks.

Re:Missed the most promising one: Java/SWT

[Anonymous Coward]

Perl? Sorry, we're talking about languages that are actually used in business apps.

C++? Sorry, we're talking about languages that don't allow programmers to do a core dump everytime they write 5 lines of code.

C#? Good luck running it on your Mac box.

Re:Missed the most promising one: Java/SWT

[Space cowboy]

[grin] The 3500-file project *is* a sub-project ... It's an enterprise asset-management system, based around collaborative nodes rather than a central machine with the application running on it. The 3500-file project is the parallellising (sp?) scripting engine built into each node. It's a reasonably complex script environment, because the idea is to distribute sections of script jobs over the available nodes (using a firing-condition model), taking into account the current environment.

I've tried it before with larger vm memory params, and it does help a bit, but not as much as I had expected. We do a *lot* of object instantiation, so I guess we're probably a corner-case for the VM (when running in the debugger, for example).

Strategic System.gc() calls (just before instantiating another Scripting engine, for example) have turned out to be useful during deployment, if not so much during development...

Simon.

Re:Missed the most promising one: Java/SWT

[Anonymous Coward]

Why do in not see the relation between core dumps and C++ ? OK apart from the fact that i am stupid my kernel is written in C!

Re:Missed the most promising one: Java/SWT

[timeOday]

You're talking about old code into new compilers. That's easy. The problem is trying to know whether the app you're writing will run on all your users' java installations. Much harder. True, Microsoft is to blame for the fact that so many people still have really old (or nonexistent) java installations, but it's still a problem for the developer. "Write once run anywhere" is a failed promise.

Re:Missed the most promising one: Java/SWT

[wdebruij]

As a C/C++ developer I'm not very familiar with java environments. How ever, after reading this post I decided to ask god and he gave me this insightful link: apparently, you can forget about the performance issue when compiling java/swt apps locally. According to the author it should work on Windows, gnome, and possibly more.

Perhaps it is time to revisit java after all those years.

then again, printf("%s\n","maybe not").

Scheme Toolkits

[bobbotron]

I was wondering what toolkit people use for GUI's written in scheme. I'd like to start developing GUI's with scheme - so far it seems like I'm limited to either the GTK scheme binding, or the plt gui toolkit.

The bloat curse

[Gnulix]

I run KDE and as such I prefer applications that use QT. However, there are plenty of good, useful applications that use GTK (Gimp comes to mind) and I don't want people to waste their time on making equivalent applications with QT nor do I want QT frontends to these apps. I can live with two toolkits, but... I run a pretty lean Debian installation, still I have to have a few extra toolkits installed. Tk for example, I hate it, it's ugly as hell, but quite a lot of useful apps use it. The big problem is that these extra toolkits will bloat your system. Not only do they use up disk space, but they will use up lots of memory when you use that one app that needs them. It's pretty pointless to have a shared toolkit library when only one or two apps use it. In other words, it has got to be one hell of a great application for me to install yet another toolkit!

Re:The bloat curse

[rubypossum]

Absolutely. Why do we need 15+ different toolkits (I'm not exagerating, count them sometime.) My theory goes like this.

Toolkit programmers like all us geeks are antisocial and tend to think that others around them are dolts. So they naturally choose to write Their Better Toolkit (tm). Because they Can Do It Better.

Then these Better toolkits get a small following of cowed developers that all think that their particular toolkit is the best (mostly because it's the first one they learned.)

The success or failure of a given toolkit will depend on how much indirect marketing the Cowed developers do for the given toolkit.

Thus... we get this list of toolkits available for linux.

Making Money == Evil?

[avdi]

The article's biggest strike against Qt is "Very business-oriented main Web site". What the hell is that about? "I'm shocked, shocked! to find marketing going on in this business!". Clue to the author: Qt is made by a company called Trolltech. Companies exist to make money for their employees and shareholders. One of the ways they do that is by (gasp) marketing themselves on the web. That particular company has gone to great lengths to accomodate free software developers; but they still have to make money somehow. If you object to their business model, just say so. But objecting to the fact that their corporate website is "very business oriented" is like objecting to the fact that Slashdot is "very geek oriented".

Re:Making Money == Evil?

[WNight]

What's is it with all of the "Poor Trolltech" sentiment in this thread? If their GUI library isn't available on Windows without paying money for a development kit and a license it's not as useful as free cross-platform libraries.

If I write some neat program for myself and friends in Linux, it'd be nice to do it with a GUI library that'd let me, with a minimum of porting hassles, release it for friends in Windows as well. Not worth the $1500 dev kit, but still handy.

Or perhaps if I was starting as a shareware developer. $1500 isn't much when the money starts coming in, but it's a lot up front.

Being that portability to Windows is a handy thing, I think the issue of QT being a business and charging for that ability is directly on topic.

Yes, we know, for the trillionth time, that the job of a company is to make money, yada, yada, yada... That doesn't mean that our job is to supply a company with money.

Re:Making Money == Evil?

[penguin7of9]

Clue to the author: Qt is made by a company called Trolltech. Companies exist to make money for their employees and shareholders. One of the ways they do that is by (gasp) marketing themselves on the web.

Yes, but software companies also try to make money by entangling their users in a web of sunk costs (training, tools) and proprietary interfaces. That is why open source advocates are often suspicious of open source efforts that come across as "too corporate".

That particular company has gone to great lengths to accomodate free software developers; but they still have to make money somehow.

Well, that is nobody's problem but theirs; nobody is under any obligation to use their software.

And, frankly, on balance, I think Troll Tech has gotten by far the better deal out of KDE's use of their toolkit. I think without KDE, Troll Tech would simply not exist anymore, while Linux probably would have a more unified and better desktop experience than the current Gnome/KDE split.

Re:Making Money == Evil?

[Arandir]

What's is it with all of the "Poor Trolltech" sentiment in this thread?

Because the article was severly biased against it, while pretending to be fair and balanced. To rephrase the question, what the fsck does a business-oriented website have to do with the quality of the toolkit? Next thing you know he'll be dissing Redhat and SuSE for the same reason.

Re:Making Money == Evil?

[licketyspit]

You're right, the guy was biased, but it was obvious he was biased based on FUD and didn't spend the time to really research Trolltech. There are a lot of reasons to be suspicious of Trolltech, from their relationship with SCO, their licensing issues and the way they handle the open source community. The fact is they're probably indebted to the open source community, KDE keeps that company alive. I'm not saying the tech is bad, it's great if you're a C++ programmer, but doesn't the community at large regard development in C as the standard?

Re:Making Money == Evil?

[WNight]

If Redhat charged $1500 for people to deploy packages on Debian, or Windows, using the RPM package format, they'd be looked at suspiciously too.

QT is trying to build a standard gui library, but that library isn't freely available anywhere as a standard should be. I think it's really important to know where libraries are available, and if it's just because they haven't been ported yet, or because they're charging for it and it'll likely never be free.

The GPL also says you can't release code under the GPL if it's patent encumbered, so if a company releases GPLed code that uses their patents it's likely that a judge would interpret that as an offer for royalty-free use of those patents by anyone who accepts the GPL on the code. If something isn't GPLed and they don't guarantee the code to be patent-unencumbered you're opening yourself up for a Unisys/LZW problem a few years down the road.

Re:Making Money == Evil?

[Anonymous Coward]

Without KDE, there would be no GNOME. GNOME was a direct reaction to KDE, when Qt did not have the free license it now does.

Re:Making Money == Evil?

[Anonymous Coward]

Without KDE, there would be no GNOME. GNOME was a direct reaction to KDE

Quite right: if the KDE project had been based on a toolkit with a reasonable license from the start, then there would have been no split. The KDE project has done grave harm to the open source community by not paying sufficient attention to software license issues from the start and thereby forcing people to start the Gnome project. I don't think KDE can ever make up for the damage it has caused to open source software, no matter how good a desktop it may become.

For KDE developers to come back now and complain about the existence of Gnome or to mock Gnome for (supposedly) being not as good as KDE is just adding insult to injury.

Re:Making Money == Evil?

[denshi]

Hi.

Qt was around years before KDE. And Trolltech was a smaller, but still successful, company back then. I was programming Qt back in 1997? 98? It was rock-solid even then. GTK+, which, I might add, was being developed for political reasons, was kind of a permanent, bloody migrane to work in. And let's focus in on the reasons again. Qt was there. Then KDE happened. Then Miguel and co pitched a fit that this well-designed app was becoming a new Linux standard, and screamed bloody hell that it was based on a non-GPLed toolkit. Qt was free on Linux, but That Wasn't Good Enough. They borrowed the toolkit from GIMP, called GTK internally, renamed it as GTK+, decided to keep it in C, and started work on it and GNOME in order to preserve GPL sanctity on the Linux desktop. Scroll forward two years. You find that KDE has continued lightyears ahead of GNOME, and that in response to the GNOMEitistas, Trolltech has first created the QPL, which the OSI rated as open-source, but since That Wasn't Good Enough, Trolltech then released Qt under the GPL, but somehow that STILL Wasn't Good Enough for the GNOMEitistas, and so the silly war continued...

I don't know if you've been around that long. But there's the background on the FUD. There's a bit of a tendency in the slashdot crowd to just accept the years old FUD and not think about it too much.

"The community at large" I guess kind of means whatever you want it to mean. If you mean "GUI developers", then, no, C is not the standard, C++ has been the standard for years. Passing C++ references and calling object methods is the way most GUI programming is done, not writing preprocessor macros to magically objectify sickeninly complex C structs and chasing function pointers around the app. If you mean, "open source programmers", then no, C is still not the standard, C++ and Java compete with all the scripting toolkits out there now. If you mean "slashdot bigots with poor grasp of history", then yes, you could say that C is the standard.

Re:Making Money == Evil?

[mabinogi]

What the hell are you talking about???

QT X11 is licensed under the GPL (or the QPL, if you prefer to accept that one instead)

It's actually been that way for a couple of years now...

and where the hell did you come up with the crap about patents?

Re:Making Money == Evil?

[WNight]

I wasn't meaning QT specifically, I mean gui libraries in general. That's why it's important to know how they're licenses and who owns/controls them.

And if you're wondering where I came up with the patent topic, I recommend that you read Slashdot. It's an interesting site where the talk about abuse of the patent system and similar things.

Re:Making Money == Evil?

[licketyspit]

Oh wow I pissed someone off. I am aware of the history of Qt and GTK+, there's no need for a lesson. I've used the qt library in the past but I choose not to use them now. I use java, C and C++ at work. My memory's not what it used to be but I seem to recall GNU coding standards saying something about using C. What I look for in a library gui or otherwise is, how compatible is across different architectures? I've had GTK+ running on windows, solaris, freebsd, openbsd, linux(x86 & ultrasparc) and it didn't cost me any money. There's a good reason to use gtk+ over qt, even if it does take a little more work. Sorry I got your dander up.

What the hell

[Kickasso]

are native widgets on X?

Re:What the hell

[Anonymous Coward]

What it means that it does not "simulate" the look and feel (like Java Swing does and Qt as well).

Instead it used the underlying widgets of each OS: on Windows the regular windows ones, on X the GTK+ ones, on Mac the Aqua ones.

But the API is the same on all platforms...so you code your app once and then you just have to re-deploy it on every platform with the specific SWT native library (e.g. on Windows its one DLL) for each platform.

Also...an extra benefit. GCC/GCJ allows to compile Java/SWT apps to native machine code, meaning no Java required on the installation machine (but then you would have to also recompile on each platform).

Check here for more info on the design architecture behind SWT:
http://eclipse.org/articles/Article-SWT-Design-1/S WT-Design-1.html

Re:What the hell

[ptr2void]

Xt? Athena? Anyway, GTK2 is much better in pretty much every aspect.

YAUR

[The Diver]

Yet
Another
Useless
Review

One tool kit left out of the article

[scharkalvin]

The article did leave out one other toolkit VDK and the VDKbuilder. VDK is a wrapper around gtk+, and vdk builder is a rad tool styled after Borland.

URLS: http://vdkbuilder.sourceforge.net/ and
http://www.programmers.net/artic/Motta/vdkbui lder/ vdkbuilder.html

Re:One tool kit left out of the article

[electromaggot]

I agree... Sad that VDK/VDKBuilder got ignored! I've used it to develop some pretty big GUIs and it saved me TONS of time.

VDKBuilder's graphical dialog layout tools (drag & drop widgets, code is auto-generated to handle them) reminds me of Microsoft's Visual Studio... of which I guess Borland is similar too. You can even make custom controls or edit the auto-generated code to fine tune your GUI.

Best of all (of course) when compared to Visual Studio, VDKBuilder is free... yet I found the two of them relatively comparable.

(OT) Good online GUI standard documentation?

[cafebabe]

While we're talking about GUIs, does anyone know where I can find some good documentation of GUI development standards online? I've done a number of Google searches but haven't found anything comprehensive.

Some developers on my team are absolutely abysmal at GUI development and, whenever we question them, they always say that what they're doing "follows the standard", which is total bulls--t. (They're just lazy and don't want to take the time to do it right.) Among other atrocities, they convinced our functional team that it is acceptable not to include any OK, Apply, or Cancel buttons on their windows and that it is "Windows standard" to provide only the X button in the upper right hand corner to close all windows (including ones for data entry). The business analysts have no experience with GUI development and are pretty intimidated by them, so they just believe whatever they say. I'd love to have some documentation to disprove them. (I've had limited success with "If it's the 'standard', can you show me ANY window from a MS application that looks like that?", but I'd like to have harder evidence.)

Re:(OT) Good online GUI standard documentation?

[Anonymous Coward]

http://msdn.microsoft.com/library/default.asp?url= /nhp/default.asp?contentid=28000443

Re:(OT) Good online GUI standard documentation?

[arkanes]

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.

Re:(OT) Good online GUI standard documentation?

[cafebabe]

Thanks for the link. That was very helpful for describing how the different widgets should behave. Sadly, our discussions usually aren't even at that level, though. We're talking the level of "If you have field with 15 options, you should use a drop-down list field and not 15 radio buttons." If anyone has a link to something along the lines of "Remedial GUI Design 101", that would be awesome.

Re:(OT) Good online GUI standard documentation?

[arkanes]

In cases like this, I recommend going to your closest technical bookstore and getting a half dozen of the biggest, heaviest, books you can find and beating the bejeezus out of your co-workers.

Re:(OT) Good online GUI standard documentation?

[cafebabe]

:-) That's the one drawback to having a virtual team. Believe me, if they were on site they'd be reeling from a series of bitchslaps.

Re:(OT) Good online GUI standard documentation?

[__past__]

Here are some more UI guidelines:

• 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"...

Important oversigt

[pong]

There is no mention of Windows.Forms at all. While mono may not be mature yet (I dunno, I haven't tried it), there is little doubt that it will be extremely popular. Once Python, Ruby and Perl implement some degree of interoperation with .net I expect Windows Forms will be the most popular GUI toolkit across C#, Visual Basic, Ruby, Python and Perl.

My US$0.02

Re:Important oversigt

[alext]

On the contrary, there's plenty of doubt.

Ximian have just been taken over by Novell, for starters.

Or do you really think that they're more interested in Mono than Exchange Connector?

Kylix

[diffuze]

My opinion is that Borland Kylix is underestimated as a RAD tool. It's absolutely brilliant as long as you can stay with c++ and qt. Look at the open version Kylix Open.

Re:Kylix

[NortWind]

I agree

The Kylix Delphi (object Pascal) seems very good to me as well. It has the same benefits as Kylix BCB, and (like BCB) you can easily develop for Windows and Linux at the same time by sticking with the Kylix components.

Mod Parent Up

[dodell]

This is the documentation I was looking to post in my original post. Please feel free to mod this comment up!

Just use XaW!

[Anonymous Coward]

Its good enough for Xterm, and its good enough for you!

Re:Just use XaW!

[d2003xx]

no, Xaw3D is better.

Re:Please avoid GTK

[InfiniteWisdom]

Let me guess... KDE zealot?

I use Gnome every day and I don't know what the hell you're talking about. I suspect neigher do you. I've never had "menus lost behind a sea of windows".

As for all the "ugliness".... Its themable. If you don't like what it looks like, choose another theme. duh.

You are a moron

[cculianu]

That's just a linking problem. You are clearly a moron. And what's with your line breaks?

Retard.

Re:You are a moron

[Anonymous Coward]

Oops. Nope. You're the moron^h^h^h^h^h big silly.
GTK runs as a DLL on windows. You need the
DLL. Just shipping someone an EXE doens't work.
Try installing GIMP for windows if you don't beleive
me.

Same with WxWindows on Linux. It requires GTK
libraries to be there. Let me spell this out for
you I WANT TO JUST SHIP ONE EXECTABLE AS THE
FINAL PRODUCT AND HAVE IT WORK. PERIOD. NO
EXTRA LIBRARIES FOR MY USERS TO DOWNLOAD.

PHP-GTK

[mcrbids]

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?

Re:Mod Parent Up

[Anonymous Coward]

tah. tronche's site was invaluable learning to write X progs at uni.

these days i'd probably consider using the ecore library, from enlightenment CVS which seems to lightly wrap the X api for convienience.

(look at www.enlightenment.org)

What about something more sexy ?

[zerodeux]

And also more experimental ... An OpenGL based toolkit (portable, fast, effects, etc) with native anti-aliased fonts, SVG and 3DS widgets ? XML serialization ? Plenty of doc and examples ? And Free Software ?

Eye candy first : http://ngl.sourceforge.net/shots.php

Then clic, clic, yada yada.

Re:What about something more sexy ?

[zerodeux]

OK, let's try with an hyperlink.

Been there, done that...

[syrja]

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.

QT != evil

[scharkalvin]

"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.

Re:QT != evil

[RDW]

Actually, I believe GTK is licensed under the LGPL (which has less strict linking criteria than the GPL), and wxWindows is LGPL with additional exceptions specifically designed to facilitate proprietary development.

Re:QT != evil

[i_really_dont_care]

The other kits do NOT give you a choice, it's the GPL or nothing!

All the other kits are licensed under the LGPL which allows for proprietary code. Case dismissed.

vy 73

Re:QT != evil

[Arandir]

Whoo hoo! Give me the freedom to take away the freedoms of others! That's the FSF spirit!

p.s. The above cheer is an example of sarcasm. The humour^H^Hr comes from GTK+ being a GNU project whose main selling point seems to be the ability to write user subjugating proprietary software.

Re:QT != evil

[mrroach]

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

Re:QT != evil

[scharkalvin]

Actually I see that you are all correct, the other toolkits are lgpl. (EVEN BETTER!) However you still might have to release the sources to any CHANGES you make in the tool kits. Sometimes you just HAVE to subclass a widget ya'know!

Re:QT != evil

[Kashif Shaikh]

MySQL does the same thing, no? I don't see people calling MySQL dual-license scheme evil!

Re:QT != evil

[i_really_dont_care]

It wasn't my intent to state that the GPL is a bad thing. The parent^2 is just mistaken because he obviously doesn't know the difference between GPL and LGPL (or doesn't want to know).

Re:QT != evil

[rubypossum]

God you QT zealots are annoying. First of all GTK is LGPL not GPL. Secondly you can't develop a commercial application for Windows and sell it using QT without paying $1500. That is, I believe the authors primary point here. If you can choose between 5 different toolkits to write a program and you think you might want to sell it on win32 then you would be a moron to use QT (or maybe you like giving away profit?)

I use QT all the time. It's great. The structure is particularly nice. But it's not that much better than GTK+ and definately not better than wxWindows. That's why my company went with wxWindows to develop our proprietary GIS software. Maybe we'll make it GPL some time down the line (I'd like to see that happen.) But not before we make $$$ off it.

Re:QT != evil

[mkone]

And this obviously erroneous post was given a score of 4. Damn. At least the author should get his facts straight before he posts. Repeat after me. GTK+ is LGPL. You can develop code for any license here.

Fonts!

[r6144]

On linux the best looking fonts are anti-aliased TrueType, which Swing doesn't support. Bitmap fonts also look good when not scaled, but it is also very non-obvious (if not impossible) to make them the default in Swing apps. So we are left with ugly non-antialiased TrueType fonts. Ugh!

(Well, maybe it is the fonts that are not as good as Windows fonts... But if you want to work with international text, even Window's unantialiased non-bitmap Chinese fonts look VERY ugly.)

Re:Fonts!

[iangoldby]

On linux the best looking fonts are anti-aliased TrueType, which Swing doesn't support.

I think that must depend on whose VM you are using. I found that to be true of the Blackdown, but Sun's VM does antialias truetype fonts with no trouble at all. This isn't a great example, but look at the captions of this.

Re:Fonts!

[Juergen Kreileder]

I think that must depend on whose VM you are using. I found that to be true of the Blackdown, but Sun's VM does antialias truetype fonts with no trouble at all. This isn't a great example, but look at the captions of this.

Can you give an example? The TT support in Sun's version and our version is virtually the same.

Re:Fonts!

[iangoldby]

Well, in the example I gave above (a simple slide-show applet), when I wrote it I had Blackdown Java installed (Gentoo Linux, I don't remember which version of the VM/SDK) the captions at the bottom of the picture seemed to display as non-antialiased text. I didn't bother too much about it, but sometime later I removed Blackdown Java and installed the Sun version, and immediately noticed that the fonts were now antialiased.

You can grab the source off the same website if you really want to. I don't have any explanation for the difference, and I'm not planning on investigating it any further.

Re:Fonts!

[Juergen Kreileder]

I don't see any antialiasing with Sun's J2SE -- it looks exactly like when running it with the Blackdown VM.

Actually a difference would have been somewhat strange. No current Linux JVM currently does antialiasing by default, you have to enable it explicitly.

(Pre-1.4.1/1.4.2 version had somewhat ugly TT rendering. Maybe you were comparing some older Blackdown version with a new Sun version.)

Re:Fonts!

[iangoldby]

No current Linux JVM currently does antialiasing by default, you have to enable it explicitly.

I did enable it - that's why I was expecting it to be rendered antialiased. Anyway, it was probably an old version of the Blackdown VM then.

Re:Canopy Group Owns Trolltech/SCO

[fault0]

~ 6.0% ownership of a PRIVATE company is not control at all. Especially when ~65% of the company is owned by employees.

-1.0000 FUD.

Why do Xlib function calls cause bloat?

[Anonymous Coward]

Believe me, I'm no fan of Xlib, but I'm confused by the statement in the article that Xlib function calls cause bloat and limit readability.

Why would there be any more bloat with Xlib calls than with any other set of toolkit function calls?

Btw, I've spent the last few months hacking with Xlib, and my personal, humble, opinion is that Xlib should only be used as a last resort.

Xlib API still K&R

[hey]

The article says the Xlib API function prototypes are still K&R. That's horrible. Since I assume
all toolkits are built on Xlib wouldn't it benefit
everyone if somebody (eg one of the toolkit makers)
fixed this horrible state of affairs.

In fact *any* improvement to Xlib be great for everyone. This suggest it would be a great area for somebody like IBM to fund.

Why another QT license?

[Anonymous Froward]

That isn't even a valid point. Qt 2.3 for Win32, free.

Well this is probably a bit off topic, but the Qt Non Commercial Edition for Microsoft Windows is covered by the license called Qt NON-COMMERCIAL LICENSE version 1.0. It specifically states that you are allowed to develop software using QT "in a non-commercial setting". Though the definition of "non-commercial" is not found in the license itself, another page says that:

"A non-commercial setting means that you must not use the package in the course of your employment or whilst engaged in activities that will be compensated. A non-commercial application is an application that cannot be sold, leased, rented or otherwise distributed for recompense."

My question is, why another license? I actually like QT. I use KDE every day and I write for QT for my private purpose. And I don't care if they charge billion dollars for Windows version. But why did they HAVE TO create yet another license that pose such a strong restriction like "you cannot earn even 1 cent using this software" when it seems (at least to me) that the GPL would have sufficed (and less restrictive)? Would somebody please enlighten?

Re:Why another QT license?

[Xerithane]

My question is, why another license? I actually like QT. I use KDE every day and I write for QT for my private purpose. And I don't care if they charge billion dollars for Windows version. But why did they HAVE TO create yet another license that pose such a strong restriction like "you cannot earn even 1 cent using this software" when it seems (at least to me) that the GPL would have sufficed (and less restrictive)? Would somebody please enlighten?

It's their lifeblood. They are trying very hard to create a commercial quality toolkit for cross-platform development. Their big threat to profits is not gaining compensation for Windows applications. Since Windows is the dominant desktop platform, that is why they want money for Windows development.

I think that it is a touch silly, but I do understand where they are coming from. If you want to do Windows development, you have to pay. Windows is a proprietary/commercial platform so they are just staying with the paradigm.

Microsoft's WM someday...

[Anonymous Coward]

Word on the street is that MS is building their own WM that runs on X. This will help to minimize the pain of porting Office, Exploder, and other MS software to *nix. But of course it won't be free. I assume they'll make the move to linux just before the linux desktop/office tools mature too much to really kill business (maybe 3-5 years). I don't know about their plans for the server side though...

Agreed. And that's not all... (rant)

[Balinares]

I have to agree. Sounds like someone with an axe to pick and yet trying to come across as an "oh look at me I'm knowledgeable and unbiased!" kind of writer. Feh.

So, let's see.

First of all, isn't it funny how the author omits to mention how a clean and thoroughly engineered class hierarchy can help you design more modular software that will be much easier to maintain and refactor? Or do people really think that the KDE project has been improving at the pace it has by mere luck?

> Very business-oriented main Web site

That's a problem how? Do you really MIND that the site provides info for people other than geeks, along with, you know, a completely up to date documentation for each version?

> Main branch depending on one company

This is either pure ignorance or a lie. Typical underhanded FUD. The main branch is GPL'ed, and the KDE Foundation was established to keep the main branch GPL'ed no matter what happens to Trolltech.
http://www.kde.org/whatiskde/kdefreeqt foundation.p hp

> Commercial developers and people wanting portability have to pay

Commercial developpers *ARE* allowed to sell GPL apps, dammit. THIS is the way of Free Software business.
And Qt 2 is available under for GPL on all the main platforms. That's for portability. Only Qt 3 for Windows requires a commercial license (this wasn't always the case, but according to interviews I read some Windows developpers would routinely use the GPL version in closed source apps, so Trolltech had to discontinue the GPL license on Windows. Thank you, guys. Thank you so much.)

> Huge sources and binaries, library itself takes ages to compile

That's C++ for you, dude. Install a binary package next time.
Additionally, and just because I'm pissed and am most willing to nitpick the bullshit out of existence, 1) Qt ships will ALL the major distribs, and a majority of minor ones -- no need to recompile it, and 2) You don't need to recompile it either for use with older software, as the API is backwards compatible -- which is not the case of all the APIs out there, which he blissfully omitted.

> Objects not referred by namespace but simple literal prefix "Q"

And that's a problem how?

> Dominant Microsoft Windows look

This is either pure ignorance or a lie. I won't even enumerate the number of looks Qt comes with *natively*.

In fact, this is so close to the usual Qt FUD you can hear from certain people that I strongly suspect that the whole purpose of the article was a clumsy attempt at slowing the growing popularity of Qt. Well, sorry, but such retarded FUD won't last three minutes on Slashdot. We may be a bunch of bickering nerds at times, but we know our shit.

If you don't like Qt and are concerned about its growing supremacy, which is your absolute right, then contribute to competing projects to help them improve. Trying to smear shit on competitors will only make your side look desperate. Is this what you want?

Rant other. Let the moderation begin, I have karma to burn.

Re:Agreed. And that's not all... (rant)

[Anonymous Coward]

>First of all, isn't it funny how the author omits to mention how a clean and thoroughly engineered class hierarchy can help you design more modular software that will be much easier to maintain and refactor? Or do people really think that the KDE project has been improving at the pace it has by mere luck?

The above quoted statement has no meaning to most people masquerading as programmers.

Using Swing over X

[Anonymous Coward]

Two Things...

• I use Netbeans over X all day because my desktop machine doesn't have enough oomph. There is a 100mhz connection between the two machines with nothing else on the link. It seems fast enough for me.
• Except: if I move the mouse out of a window too fast, the tooltips go blank and leave a dead window on the screen. Does anyone know anything about this?

-- ac at work

Re:Using Swing over X

[Querty]

I use Netbeans over X all day because my desktop machine doesn't have enough oomph. There is a 100mhz connection between the two machines with nothing else on the link. It seems fast enough for me.

You have inadvertedly SOOOO proven the parent poster's point ;-)

Qt compile times

[jeti]

In my experience, compiling applications for Qt
also takes a while. A lot of the Qt classes use
shared data. They are often used by value in
parameters and class members.

Therefore Qt header files tend to include lots of
other Qt headers. Since there currently is no PCH
support, compile times go up quite a bit.

Re:Qt compile times

[__past__]

Recent GCC versions do have (limited) support for precompiled headers. Shouldn't that speed up Qt app builds quite a bit, or does it not work for some reason?

Re:Qt compile times

[Anonymous Coward]

Try using forward declaration of the class instead of including the header. Building against a library should be a relatively fast process.

Re:Please avoid GTK

[samhalliday]

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.

Re:Please avoid GTK

[Malc]

Theming doesn't work so well when you don't use GNOME. It works even worse when the apps aren't used under Linux/X.

I find it quite amusing how my original post got moderated down as flamebait rather than debated. I guess the truth hurts. The GTK team could learn a lot from some of the other tool kit makers - yes, including Trolltech.

Oh, I do have a little experience of GNOME. I used the Ximian Desktop version of it for at least a year before I got fed-up with its crapiness.

Making Money == Good for Free Software

[conradp]

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!

Re:Making Money == Good for Free Software

[__past__]

Good luck finding another GPLed UI library. All I know of use a more liberal license, most seem to be under the LGPL.

I do not have a moral problem with Trolltechs licensing scheme - they wrote the code, they decide how others may use it. It obviously works for them. On the other hand, the dual licensing is not ideal for me, for simple selfish reasons - if I want to write closed-sourced apps, I can get perfectly OK alternatives next door, without having to pay. And Qt is not that much better - in fact, unless you are insane enough to write GUI apps in C, I like the Gtk/Gnome API much better, the bindings generally make more sense to me than the ones of Qt. YMMV

I don't think there is any problem there, everybody is behaving fine and doing what makes most sense to them. It will be interesting to see the long-term consequences, though - my prediction is that, in a few years, Gnome will be the preferred desktop for commercial settings, with more proprietary apps available, while KDE will be more for the home-user/eye-candy-lover/hacker camp.

Tcl/Tk

[dentar]

Tcl/Tk allows you to write GUIs very quickly without the need for C/C++, but you can mix 'em up with C/C++ if you like.

Downside: The widgets aren't pretty.
Upside: I can whip out a GUI in a day!

we need X resources!

[Anonymous Coward]

Most popular X toolkits tick me off. If it doesn't support X resources (e.g. ~/.Xdefaults), it's bordering on useless for me. If it supports the editres protocol, that's a huge plus for me as well.

Agreed there are some nice non-C toolkits to code for (e.g. GNUstep, already mentioned in other posts). For C toolkits, I've tried a few (the popular ones anyway), and my conclusion is that anything other than Motif is absolute trash. Unfortunately Motif on Linux is still a little iffy. There are a bunch of minor compatibility issue that Lesstif has.

But for the love of god, X resources! X resources man! So flexible, so easy to use, so comforting.

X "Windows" and also K&R prototypes

[metalwheaties]

The proper term is "X Window System" as Bob Scheifler(sp?) has always been happy to pound into everyone's head.

The author says that the Xlib API uses K&R prototypes which is simply untrue (and never has been). The Xlib.h interface file, for example, has the option of conditially supporting really old compilers that don't have ANSI prototype capability, but this is almost never used anymore. The prototypes are there, and lots of excellent programming practices can be found therein.

(By the way, I'm not associated with any X related business and have no axe to grind other than assuring accurate reporting. I did develop most of the original X server for MacOS, which was, of course, named MacX.)

My 2 cents

[truth_revealed]

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

Re:My 2 cents

[Anonymous Coward]

FOX:
- No Unicode support, but planned for FOX 2.0
- Uses C++ namespace "FX" in current 1.1 development releases and will be in FOX 2.0
- small but incredibly helpful user base (check the mailing lists!)

Re:My 2 cents

[Anonymous Coward]

WxWindows: - supports the most platforms, has native look.

Unlike the other toolkits, it actually does use native widgets. I suppose you could quibble and complain that there are no "Linux" native widgets, but since you can choose between GTK, X11 or Motif, it's sort of moot.

There have been a number of attempts to create a version of wxWindows that supports Qt, but due to a number of issues, including apathy, issues with the MOC - but mostly because of legal posturing from Trolltech, it never happened.

Re:My 2 cents

[Ilan Volow]

One area I think where WxWindows is still unsatisfactory is in the RAD department. All the WxWindow RAD apps (XRCedit, Boa Constructor, even WxDesigner) I've used to don't come anywhere near to the ease or polish of Qt Designer or Glade (and I use the words "ease" and "polish" in a relative sense; neither holds a candle to Apple's InterfaceBuilder).

For me, the lack of a quality RAD environment has been the real deal-breaker with WxWindows. I only use that toolkit if I have to target all three platforms using Python(which is where it sucks the least compared to all other GUI toolkits).

Re:My 2 cents

[JLyle]

FOX... only supports UNIX (X11) and Windows

There is no native Mac OS X port yet, but it works very well under Apple's X11 server.

Re:My 2 cents

[renoX]

Legal posturing from Trolltech?

Could you give a reference?
Qt/X11 is GPL, if wxWindows over Qt is GPL too then their wouldn't be any problem.
I don't think that a wxWindows could be LGPL if it was made above Qt, but I'm not sure..

Re:My 2 cents

[lspd]

Call me crazy, but I never really liked Glade. QT/KDE-Designer is ok, but the documentation on integrating it's use into Kdevelop was rather poor the last time I looked.

As ass-backwards as it sounds, I find it easier to put the UI together by hand in QT, GTK and WX. I think if you look through the source code for most of the projects out there you'll see that the designers took the same path and limited use of Glade and QT-Designer to popup dialogs and wizards.

Still, I'd be perfectly happy to see both QT and GTK integrate their RAD tools proprely into the 2 main IDEs (anjuta and kdevelop.) As things stand though, I don't see either one competing well with Visual C++ in this regard.

Still, your point is valid though. WX is lagging in this area. Given the state of the QT and GTK offerings though, I wouldn't say it's critical.

Re:My 2 cents

[RJfortyfive]

>>One area I think where WxWindows is still unsatisfactory is in the RAD department

>>using Python

Dude - do yourself a favor and check out WxGlade -it spits out good Python, and the author is very responsive to suggestions. The rest of the RAD tools for WX did not make the cut for me. -Don

Re:My 2 cents

[RJfortyfive]

I would agree with you in the main, but add these points

QT (and KDevelop / QTDesigner) are really the coolest. Too bad they have priced themselves out of the small developer market.

Borland Kylix C++ uses QT under the hood, but who knows whether Borland will continue that product. It's been a _very_ long time since it was released. With Borland's infatuation with .NET, I don't really think we will ever see a native *Nix Kylix 4.x.

FLTK is really cool, very nice people, but I had concerns with the fact that you could only have static callbacks, and the fact that it did not use sizers or layout managers, and getting some of the panels to size properly is a royal pain in the butt.

WxWindows is the the most mature of the free toolkits, but I walked away. I found that it really did not support Threads, really did not support a integral double-buffered window, and I found a number of gaps in the docs. When I raised the issue of updating the docs, there was a not-very-friendly flame war where everyone hated one or more doc structures, and so nothing was done.

FOX is my chosen destination for now. It has very good drawing (minimal or no flicker), layout managers, and threads (in add-on libs, at least). The only problem is a GUI RAD tool, and we've almost got something usable with FOX DialogEditor.

Sort of half-assed

[Cranx]

This review was a bit half-assed and I couldn't get much further than his statement that user-generated events are particular to X and that Win32 doesn't have them.

Uhm, okies.

The list of GUI toolkits, though, I'm sure is useful to many people, so that much was nice. Go check them out for yourselves though, folks.

What about XVT?

[Xentax]

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

Stop spreading lies

[Anonymous Coward]

If you had the decency to give correct numbers,
your post would be much more relevant.
- the JRE download is 14,153,852 bytes for the latest version. And you download it once for all
java applications. How big is Qt?

- there is no Java version hell. Java is much more mature when it comes to different versions. You can still run Java classes compiled with version 1.0.

- 40meg memory? Speaking of Java 1.2, you might be right. Nowadays memory usage has been greatly reduced. Futher work is on the way

- latest hardware? Java runs sufficiently fast on my 700Mhz Duron box.

So, get your facts straight before posting.

Re:Stop spreading lies

[Soul-Burn666]

"How big is Qt?"
10mb download for the whole devel pack.
The library needed to run a prog is zipped to 1.3mb.

(These number refer to the GPL Win32 Qt 2.3.0)

Re:Stop spreading lies

[baxissimo]

(These number refer to the GPL Win32 Qt 2.3.0)

Just to get the facts right, the 2.3.0 version of Qt for Win32 is most definitely NOT GPL. The source code is not available and the use of the binaries is restricted to "non-commercial" activities. Incidentally this apparently also excludes the use of that version of Qt for academic research, since Trolltech considers research to be "commercial activity". See the FAQ.

Re:Stop spreading lies

[PW2]

>> latest hardware? Java runs sufficiently fast on my 700Mhz Duron box.

compared to MFC/etc which runs fine on 75Mhz machines

Namespaces vs. name munging

[Chalst]

The author seems to have a bee in his bonnet about using name munging. While it is inelegant, there is the virtue of simplicity in the arrangement, and the important issue is what sort of risks name munging creates for programmers. The Common LISP module&macro system has shown that name munging need not be problematic in practice.

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.

Didn't cover XForms and got its license wrong

[psgalbraith]

FLTK is the C++ successor to the XForms library (which is written in plain C), so I won't cover the latter here. XForms is not Free Software and is free of charge only for non-commercial use.

XForms has been free software, under the LGPL, for a while now.

See the Debian package in the main archive.

Or you could use VisualWorks

[Lord of the Fries]

Doesn't have the bloat of the Java library (Swing was largely ripped off from VisualWorks in the first place). Is binary xplatform. I run apps on my 486 as well as my 100MHz Mac, with no problems at all. I'd say the exe's are slightly larger than statically linked C programs (but not by major factors). The UI's plenty responsive.

And since when

[Kickasso]

GTK+ is the underlying widget set of X?

Re:And since when

[Anonymous Coward]

Fine...if you want to speak semantics. GTK+ is the most popular one. They had one that was Motif-based, but everyone screamed to replace it with a GTK+ one.

Theoretically, they could develop one that uses Qt as the underlying engine too (to give it a native KDE look), but Trolltech's license gets in the way...

It's the truth

[Anonymous Coward]

not only is the memory footprint huge, it never goes down.

The garbage collection is just that; garbage.

I have never understood the need for a language that is syntactically the same as C/C++ with the only added feature being reduced speed, and that alleged cross-platform compatibility, which we all know is a lie.

use native, non-cross platform toolkits

[penguin7of9]

You may notice that the "gold standard" of GUIs that people like to hold up for Linux, Microsoft and Apple, are not cross platform. Neither company wastes time trying to build something that works well with a GDI, X11, and DisplayPDF backend. And there are good reasons for that.

Picking APIs that can be supported on multiple platforms is a lot of work, and implementing them on multiple platforms is even harder. Furthermore, some things simply cannot be supported well in a cross-platform manner, and conventions from one platform inevitably spill over to another platform.

For example, many cross-platform toolkits have no notion of remote displays. Even if the toolkit supports it, application programmers still hardcode assumptions about specific environments (e.g., on Windows, preferences are usually tied to the machine, while on X11, they should be tied to the display). The wxWindows, Mozilla, Qt, and Java/Swing toolkits are full of such compromises and assumptions, as are applications written in them.

Developers of a high quality Linux desktop should write specifically to X11, the native Linux graphics subsystem and not waste time or effort on any kind of cross-platform support; the competition isn't wasting time either. Cross-platform toolkits have their uses (I usually use wxWindows or FLTK), namely for when you really want to create a cross-platform application, but they are not a good choice for the core apps.

Of course, many people who do use cross-platform toolkits and notice that they often support X11 less well than Windows (because of the smaller market) blame X11 and want to fix the problem by replacing X11 with something just like GDI. To those people I suggest: contribute to an open source Windows clone if you like; don't try to make Linux into Windows.

Great

[Anonymous Coward]

more interpreted code hell from the Java freaks.

Re:Great

[Anonymous Coward]

All your code are belong to us.

BTW, as I mentioned before GCC/GCJ allows you to compile SWT apps to native machine code, no interpreted Java, pure machine code as if you coded in C/

Re:Please avoid GTK

[Malc]

BTW, themes are just eye candy. It's functionality that needs to be fixed. Personally, I don't like fiddly with themese. I've got better things to do with my time than trying to hide every bad programmers personal tastes.

From somebody else's post it's apparent that a lot of these apps are using an older version of the toolkit, so I will have investigate further to see if the situation has improved.

Free Speech, not Free Oxygen

[Ilan Volow]

True, there's nothing technically preventing you from selling GPL applications.

There's also nothing technically preventing you from putting air in a jar and selling it at a flea market.

I'm not making a judgement about the GPL one way or another, I just think it's silly to flame someone over recognizing that you can't practically sell a public commodity that anyone can get for free (which means you have to get creative and sell something with it like support, beanie babies, free escort service, etc).

Re:Free Speech, not Free Oxygen

[e8johan]

Think RedHat, SuSe, IBM, etc. Open Source software can pay - big time!

Re:Please avoid GTK

[InfiniteWisdom]

I find it quite amusing how my original post got moderated down as flamebait rather than debated

Maybe its because it was flamebait. There was no material to debate there. Just a rabid dog post about how much you hate GTK. If you said you don't like it because it does (or doesn't) do x, y, z then there is scope for debate.

C'mon

[Anonymous Coward]

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.

This toolkit blows the rest away!!!

[Admiral Akbar]

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 :)

Re:This toolkit blows the rest away!!!

[joshsnow]

Well, all I can see there is something called Eiffel Envision 1.2 which is a plugin for MS-Visual Studio.NET...

Re:This toolkit blows the rest away!!!

[Anonymous Coward]

The Vision2 toolkit is written in Eiffel and is included with the Eiffel compiler suite (either EiffelStudio standalone for Unix variants and Windows or the VS.Net plugin Envision). The emphasis is on design and ease of use, with Design by Contract debugging with this thing is a complete no-brainer. To use Vision2 you will need to download one of the compiler suites (either Studio or Envision).

Re:Xlib API still K&R

[penguin7of9]

The article says the Xlib API function prototypes are still K&R.

The Xlib API still has support for K&R, but it also has prototypes.

In fact *any* improvement to Xlib be great for everyone. This suggest it would be a great area for somebody like IBM to fund.

Xlib is just a C library for accessing the X11 protocol. There are several libraries and toolkits that don't go through Xlib at all (e.g., CLX, Escher). But Xlib is pretty good at what it does; it's complicated because X11 has a lot of features.

There has been some work on a new low-level C library for accessing X11 servers, but the community just doesn't seem to have that much interest.

They always seem to miss....

[Cnik70]

the toolkits provided via java. The benefits: looks the same on just about any platform, generally free. The cons: closed source, a bit slow (but greatly improving as of 1.4.2).

annoying perl

[axxackall]

Programming on Perl is annoying in general, by itself, no matter with TK or something else.

Just try Tcl/Tk or Python/Tkinter and enjoy.

Java is locking in

[axxackall]

The real toolkit must be OS idependent *AND* language independent. In Python, Tcl, Perl, Scheme and Lisp I have non-GUI libraries doing very useful things and I want them to have GUI using the same toolkit. With SWT I am locked in in Java and that's exactly what I want to avoid.

The GUI Toolkit, Framework Page

[Andy Tai]

This may be of interest: a web page that lists almost all GUI toolkits out there, for virtually all platforms (Windows, X Windows, MacOS, etc.) and all major languages (C, C++, Java, Perl, Python, etc.)

The GUI Toolkit, Framework Page
at http://www.atai.org/guitool/

Never let programmers design GUI's

[Ilan Volow]

You made the fatal mistake of letting programmers design user interfaces. Always let programmers design algorithms, and let them design precious little else.

Honestly, it won't really matter what kind of information you show those guys. They'll heel drag even if Bill Gates walks into their office and tells them they're completely wrong.

What you need to do first is design the UI at the start of the project, before any code is written. Once major code is written, most programmers are going to be obstinant as hell about going back and changing something just because someone with far less computing knowledge than themselves has trouble with it. When you do this preliminary design, do it on paper and pencil. Paper by its nature is extremely non-modal, which means whatever design you do will probably result in fewer annoying dialogs and will feel more natural to the end-user. Also, if you do a design on paper, you'll have less reservation about changing the design (as opposed to if you did a mock-up in photoshop, visual c++, Glade, etc) because you put less work into it.

The next project you work on, you might actually want to go ahead and hire a usability specialist who will do much of this annoying stuff for you and might do some testing of the proposed UI on Normal People(tm). If you do this, again make sure you bring the guy in at the start of the project; too often usability specialists are brought in to play damage control after way too much significant code is written, and there's not much they can do because too much code has already been written.

Finally, buy this book and show it to some of your programmers. Most of them will probably not come around to your side, but at least you can say you tried.

Totally missed the point of Qt

[frostfreek]

Qt has THE BEST object-oriented design that I have seen, by far. The widget hierarchy, methods, etc... have a very clean and consistent implementation. Also, the documentation is fantastic! It is always current wrt. the library.

- The ease of code integration into Designer by OO derivation is fantastic.
- The speed at which GUI apps can be developed, using TT's Designer is great!
- The qmake program, while not as capable as automake etc..., is still simple and easy to use. Plus, it takes care of his whining about extra steps.
The 'strengths' section on Qt is hopelessly lacking.

I know that Gtk+ is also OO, but to me it seems they bend over backwards to use C++ features from C, creating a bit of a mess. It is not as clean or consistent, either.

As well, while I H8 Motif, the fact that it was overlooked in this review is pretty bad.

A BIG FAN of Qt,
Jamie.

Threads?

[sleepingsquirrel]

Is it possible to use threads (>5.6.0 threads) in a Perl/Tk program yet? (you know, one for the gui and others for the cpu intensive stuff). Last I heard, you could try it but it might blow up in your face. Will Perl 6.0 or a new version of Tk solve the problem?

OpenMotif 2.2

[lordmage]

For the original GUI master and for the ease of use..

BXPro and Viewkit that lives on Top of OpenMotif 2.2.

http://www.openmotif.org

Sun/HP and so many more platforms already have GUI builders using the UIL programming language. BXPro/Uimx/Sun Workshop/etc.. Motif is alive and strong.

ZooLib Cross_Platform Application Toolkit

[MichaelCrawford]

The ZooLib cross-platform application toolkit has been around for thirteen years, making it even more mature than wxWindows. Yet it is still in active development.

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:

• Freeing the Developer from OS Vendor Shackles

Re:Please avoid GTK

[InfiniteWisdom]

Sure mine was flamebait too... but I'm not the one whining about how my comment got moded flamebait.

Cost

[Anonymous Coward]

I'm tired of ppl complaining about having to pay for stuff. So what if Qt costs money to product a commercial application. They did a lot of work in the begining so we can write an applicaiton eaisly and sell it. Should they not get a cutt of our profit?

XUL

[hackrobat]

XUL (pronounced "zool").

• Cross-platform
• Based on open standards (XML)
• Extremely easy to customise and play around with
• One major project as a proof of concept: Mozilla (Firebird and Thunderbird)

lol so true

[bdrasin]

ok, so this is off-off-topic, but yes Java is mostly fuX0red up Smalltalk with superficially c-like syntax, and Swing is basically a fuX0red up VisualWorks toolkit (although its gotten quite a bit less bad lately).
Ah, well-Java pays the bills and Smalltalk is deader than dead, so what can you do..

Re:lol so true

[Lord of the Fries]

Doesn't pay my bills. When somebody (including my employer) asks me to get a job done, I use the tools that are best for the job. Which is often (but not always) Smalltalk. But I choose, not them. When it comes to UIs, I was simply positing that VW gave a nice intermediate point between the 2 previous posts which gave the two extremes (big bloated but xplatform vs small fast but not as xplatform).

Who needs anything but

[Anonymous Coward]

Visual Basic.Net!

THIS ARTICLE IS SO BIASED

[Anonymous Coward]

OMG how can /. post this. Please ./ admins stop posting anti-KDE aarticle sunless they actually have some serious merit. gDeskelts for example , how is it supposed to be architecturally superior to SK? It doesen't even have all the features.

GNOMEers always seem to call KDe technologies hacks and than copy them. DCOP, Kparts they were all called "hacks" and now they're trying to clone them. This is just another very baised article.

Very uninformed article

[baxissimo]

People have mostly been harping on how baseless this guy's criticisms of Qt are. But it's not just Qt where the facts are wrong. The whole thing is a pile of uninformed troll droppings. He criticizes FOX for requiring the FX_IMPLEMENT macro, but completely ignores the very similar macros that wxWindows uses, like DECLARE_EVENT_TABLE()and IMPLEMENT_APP(), and Qt's QOBJECT macro. Then there's a criticism of FOX requiring you to fiddle with message id enums, but this is also applicable to wxWindows. It's just a side effect of using enums and message tables for identifying messages.

Then there's the RAD Y/N column. FLTK's FLUID is a very basic code generator for FLTK dialogs. It's got nowhere near the functionality (or usability) of Qt's QDesigner, or from what I can see GTK's GLADE. FLUID hardly qualifies as a RAD tool.

Anyway, this article is a very shallow analysis of GUI toolkits that seems to be culled mostly from reading the web pages of the projects involved. This guy doesn't seem to have spent any significant amount of time actually *using* these toolkits, or talking to people who have.

stale

[Anonymous Coward]

Geez, rack up yet another stale news article to /.

That article has been up there for quite some time now. Also see earlier posting several weeks ago on osnews.com pointing out same.

Other than that it is a decent summary of the pros/cons of the various available X11/other GUItoolkits out there, or at least the ones really worth bothering with.

Useless article

[njdj]

I went through the toolkit selection process a few months ago. To pick a toolkit, you have to do much more than this guy did. You have to use the toolkits - or at least try to.

If you do this you will soon discover much more important criteria than this review discusses:

1. Is the documentation accurate, complete and up-to-date?
2. Is the package buggy?
3. How easy is it to make mistakes in the use of the package, and how hard is it to find them?

Personally, I want to spend my time on my code, not fixing bugs in the package, or figuring out what the docs ought to say. YMMV of course. Anyway, these criteria ruled out Fox and FLTK. In the end I went with wxWindows. Things might have changed since I did my evaluation, but those criteria are the ones that matter. The review was just worthless fluff.

Re:Why would you want to use anything but Qt?

[spirality]

- Never mind that Swing is just plain ugly too, at least the metal style.
- Swing is SLOW (someone has mentioned this, but I'll say it again because it's that slow).
- 3D Graphics are a JOKE if you want to use any high end rendering engine (e.g. TGS or TSA).

In the last year I programmed Swing for 3 months and then dumped it over the 3D limitation. I then spent about 1 and 1/2 months reimplementing my Swing GUI in Qt. The difference was astounding.

After that Qt was the obvious decesion. It is actively developed, there is good support, the GUIs are responsive, and in many cases the API is much better than Swing, and only in a few cases more difficult.

Signals and Slots are a god send.

In the end my use of Qt made me switch to KDE too. :) That after using GNOME since its Alpha days.

It's unthinkable that anyone would use anything but Qt for GUI development. It is by far the most mature cross platform toolkit out there. The only two that can even come close are GNOME and wxWindows, but really who wants to write in plain C? It takes three times as much code to accomplish the same task as in C++.

That's my two cents... :)

-Craig.

Bias

[lspd]

The author of the article seems to be a bit biased towards GTK. He fails to mention though that GTK is often used in conjunction with Glib, Gnome, GDK, Bonobo, and Gnome-VFS/Ghttp. As a complete group, these are difficult to use and poorly documented in far too many places.

QT is well documented, consistent and stable but the licensing terms are a bit vicious if you want to do any commercial development. I'd use QT exclusively if it was LGPL, but I can't afford to shell out $3000 for a Win32 and Linux license.

wxWindows has some flaws when it comes to stability and features, but it includes all of the core functionality in one package, it's well documented, the license is very generous, and the API is simple to use for complex tasks. As nice as a well written GTK app looks, I'd much rather write or debug a wxGTK app since the learning curve is so much easier to overcome.

Take a look at Galeon if you don't believe me. After years of working with GTK, those developers still can't figure out why bonobo popup windows don't respond properly when GTK pops a window. The documentation is bad and the libraries are too complex. Hopefully this will change in the future. I'd love to see GTK and Gnome become the defacto standards, but as-is they're too complex.

Re:Bias

[cranos]

I'll second that. When I first started looking at which framework to use for my first C/C++ project I had a look at QT, GTK and wxGTK. The first two required one hell of a steep learning curve for someone who had up until then had been a web guy,(developer, NOT designer).

wxGTK is pretty good for those just starting out in the area of GUI design and development.

Unix .so-hell? No thanks, give me OS X!

[RevAaron]

So many comments in this thread say something like: "Yeah, all these GUI toolkits are fine and dandy, but so many are a hassle when it comes to deployment- multiple version of GTK+ and Qt, a few desktop libraries here and there... Welcome to Unix .so hell!"

It doesn't have to be that way.

It's a shame the Linux folks don't steal the good ideas from OS X- rather than just making shitty Aqua wanna-be themes for their toolkit and desktops. OS X's system of bundles and frameworks is an awesome way to deal with libraries- pretty seamless management of different versions of the library, OS version, architecture, etc. Just download the framework and move it into /System/Library/Frameworks (available to everyone on the system) or ~/Library/Frameworks (just to you).

Perl is fun! What planet did you come from?

[Anonymous Coward]

Must be one of them bozos from pascal, java, python land...(academic toy teaching languages)

In c, c++, and perl land (practical, ugly, real-world languages), we have loads of fun.

GUI toolkits and other frameworks

[Sweetshark]

I am using gentoo and fluxbox and find it most annoying that even small gtk-based apps use a *lot* of other framework-libs like (example gnome):
[ebuild N ] gnome-base/ORBit-0.5.17
[ebuild N ] gnome-base/oaf-0.6.10
[ebuild N ] gnome-base/gnome-libs-1.4.2
[ebuild N ] gnome-base/gnome-print-0.35-r3
[ebuild N ] gnome-base/bonobo-1.0.22
[ebuild N ] gnome-base/libglade-0.17-r6
[ebuild N ] gnome-base/ORBit2-2.6.2
[ebuild N ] gnome-base/gconf-2.2.0
[ebuild N ] gnome-base/bonobo-activation-2.2.2
[ebuild N ] gnome-base/libbonobo-2.2.2
[ebuild N ] gnome-base/libglade-2.0.1
[ebuild N ] gnome-base/libgnomecanvas-2.2.0.2
[ebuild N ] gnome-base/gnome-mime-data-2.2.0
[ebuild N ] gnome-base/gnome-vfs-2.2.4
[ebuild N ] gnome-base/libgnome-2.2.2
[ebuild N ] gnome-base/libbonoboui-2.2.2
[ebuild N ] gnome-base/libgnomeui-2.2.1
[ebuild N ] app-text/gnome-spell-1.0.4
[ebuild N ] gnome-base/libgnomeprint-2.2.1.2
[ebuild N ] gnome-base/libgnomeprintui-2.2.1.2
[ebuild N ] gnome-extra/gal-1.99.8
[ebuild N ] gnome-base/gail-1.2.1
[ebuild N ] gnome-extra/libgtkhtml-3.0.7
[ebuild N ] gnome-extra/libgtkhtml-2.2.3
[ebuild N ] gnome-base/libghttp-1.0.9-r3
[ebuild N ] app-doc/ebook-libgnome-1.2

although I dont intend to use gnome.
Are these really needed for these simple apps? I just would like to enjoy a lightweight desktop. To make it worse, these libs for the same task are existent for QT/KDE and GTK/Gnome.
Are the KDE/Gnome libs really making it significantly easier to develop a app - or would it be better to just use the toolkit (QT/GTK) , like for example lyx did with qt and leave the desktop libs alone.
I dont think a KDE or QT app would use gconf for example anyway (I am guessing here...)
Greetz, Bjorn

Re:Why would you want to use anything but Qt?

[_|()|\|]

The only two that can even come close [to Qt] are GNOME and wxWindows, but really who wants to write in plain C?

I don't touch C, except when I'm submitting patches to the GNOME libraries. I use PyGTK, the Python binding. James Henstridge and friends have done a bang-up job. GTK+, GLADE, libglade, PyGTK, and PyGNOME are a great set of tools. My biggest concern with GNOME is the apparent lack of a commitment to maintain backwards compatibility. This has hurt Galeon and GnuCash, I think, to say nothing of the time wasted porting other projects from GNOME 1 to GNOME 2. Maybe they'll have this worked out when it's a little more mature.

While I haven't spent as much time with PyQt, it didn't blow me away the way PyGTK did. It uses old-style, rather than new-style, classes. PyKDE is a separate project: while the latest release of PyQt is 3.7, you have to stay at 3.5 if you want to use PyKDE. Finally, the 250-GBP commercial license fee is ridiculous. I guess they have to pay for the Qt commercial license, somehow.

X-Windows does not work well over HTTP

[Tablizer]

What is really needed is a GUI protocol that works reasonable over HTTP. HTTP is becoming the standard network protocol for good or bad, and other protocols require too much fire-wall red tape and other issues.

X-Windows is not well suited for HTTP because it requires fast turnaround time for responses, and can be rather bandwidth intensive. I suggest that something like XUL, XWT, or SCGUI (my pet) be looked into, at least for typical business-like forms. (Games and multimedia may be a different issue.)

Re:X-Windows does not work well over HTTP

[Cheeze]

What a bad idea. Why would you strip X-Windows of it's protocol and try to say it needs to run over a protocol not specifically designed for it? No one would suggest rewriting nfs to work over FTP just so you can get around a firewall. X-Windows has it's own protocol (and entry in /etc/services) for a reason: Because it's been there forever.

You even agree with me in your second statement when you claim that "X-Windows is not well suited for HTTP".

Re:X-Windows does not work well over HTTP

[Tablizer]

I am not sure what your point is. HTTP is the most common and easy-to-access communications protocol around due to the web and other momentum. I don't see this changing just to accomodate X-Windows.

Ouch

[wrinkledshirt]

Quantrix, a multidimensionnal spreadshit

<sound of jokes writing themselves>

Re:Please avoid GTK

[Anonymous Coward]

Bitch and moan just because it doesn't suck your cock while being exactly like what you're used to using in every other little way.
Worthless flamebait got modded appropriately.

Re:Why would you want to use anything but Qt?

[spirality]

And performance is acceptable I assume?

Re:Why would you want to use anything but Qt?

[_|()|\|]

Yes, performance is acceptable even on a lowly Pentium Pro 200 over the network. So far, I've built pretty simple prototypes. I'm not sure how well libglade and Python will scale.

Libglade loads an XML file at run time that was created with GLADE, the user interface builder. I wonder whether the load times will increase appreciably as the application gets more complex.

Python isn't the fastest language and doesn't have the best threading support. I'm not sure how it will deal with rapid-fire signals, like mouse motion events and time outs (say, for animating a spinner logo). I don't really anticipate needing to handle these in my current project, but I'd like to test them.

If Python doesn't scale well, I can switch from PyGTK to gtkmm or GTK+. If libglade doesn't scale well, I can switch to generated code.

Motif / OpenMotif / LessTif

[Anonymous Coward]

I would have figured that Motif would be something that would have been compared to...

does anyone know why Motif isn't included?