Slashdot Mirror
GTK-- vs. QT
spirality asks: "The company I work for is getting ready to decide on a GUI Toolkit for
our Computational Modeling Toolkit (CoMeT, www.cometsolutions.com). We would like C++ compatibility and ports to various Unices and Win32 platforms. Not supprisingly we've come up with two choices, GTK-- and QT. I've attempted to compare the two by doing alot of web surfing and searching, but I've come up with things that are consistently one or more years old. So, the question I pose is what are the (dis)advatages of GTK-- and QT, and why would I choose one of these toolkits over the other? Overall functionality, momentum for future growth, ease of use, licensing, and pretty much anything else is relevant to our decision." With QT now at version 3.0 and GTK now in the 1.2.x revisions, maybe it's time to give the two libraries some fair comparison and discuss the new features, advantages, and disadvantages of each?
If you intend to develop a closed-source product, the licence of both library will probably need to be evaluated too. If you go for
an open licence, then it's of minor importance.
(Qt requires licencing fees if you want to keep
your sources closed).
My suggestion - try them out.
;-)
Come up with a few small use cases and let your developers loose on everything you can get your hands on. Both Qt and GTK+ are freely available enough for that to be a useful exercise.
You might find that, while Qt has nicer abstractions, and provides a familiar set of classes which are (IMO) far superior to MFC... perhaps GTK has a slight edge for lower level work (which it sounds like you might get involved in). Also, see which interface builder tools your team feels most comfortable with.
The problem with this question is that the replies are likely to degenerate quickly into a C vs. C++ rant-a-thon. Yes, GTK is entirely written in C. But it *is* object oriented. It seems strange to everyone at first, but just because a language doesn't support particular features, doesn't mean that you can't use a particular programming style. OO methodology is just as relevant to C programmers as to C++ or Java programmers.
If your programmers are good, they'll write good code whatever the toolkit. Just make sure everyone thinks that they got a say in the decision.
These sigs are more interesting tha
Developing for a professional product I would always go with as many professional tools as possible.
To me QT seems to be the FAR better decision. It has true interoperablity between Win32, MacOS X and X11.
QT is C++ from the ground up, GTK-- is wrapping GTK++.
Furthermore with GTK you definitely write more code to accomplish the same.
QT 3 gives you access to SQL-databases from its widgets.
QT comes with a very good interface builder.
QT based programes feel snappier than GTK based ones.
One drawback might be that you have to preprocess (actually your Makefile has to) your code before its ready for the compiler, but that's not a big deal.
With Kdevelop you have access to a very good IDE.
One thing I don't know is how QT works in terms of different GUI threads, but I neither know for GTK.
So please, go with QT and be happy
A much harder decision would be: What should I use for my Web-Frontend, mod_perl or PHP... but that's a different story!
I'm not trying to sound stupid or off-topic here, but have you considered Mozilla? Beyond ther browser, they've developed a really interesting cross-platform C++ (and JavaScript) development platform. For a start there's a cross platform implementation of COM and you can develop your UI's in an XML dialect called XUL.
You are correct. I have developed with QT for around 3 years now, and back then, I did check out GTK--, and it seemed very much a hodge-podge. I can't imagine it being any better now. I use QT on linux and windows and am going to be porting my program to the SL-5000D. (with the good graces of Sharp) How cool is that?
If I had a Mac, I'd port it to that.
-- "Perceptions create reality. By changing your perceptions you change your reality."
Being cross-platform is a major selling point for commerical Qt users, however, so if you need your apps to work on Windows then it's clearly the way to go.
Absolutely.
One important thing to note about Qt is the fact that it ain't a wrapper around existing GUI APIs. It emulates the different GUIs out there, so it does the drawing itself, avoiding going through some additional API layers. That translates into a fast and responsive GUI.
I tried it on both Windows and Linux using the platform's native GUI and GUIs from other platforms, i.e. the Motif or CDE style on Windows, the Windows style on Linux. It is very convincing and very fast.
When performance matters, I definitely go with Qt.
Watch out for that "non-commercial" license on Windows though. It might not be appropriate for what you are doing. Your company will probably have to acquire a Qt license for Windows.
Just because your voice reaches halfway around the world doesn't mean you are wiser than when it reached only to the end
Geez. Talk about flamebait topic. Personally (and personal opinion only, here), I'd say, Qt is better designed, clearer, and easier from a programming standpoint - but it's actually not clean C++, what with its dodgy signals/slots stuff, that gtk-- manages to do within the bounds of the language.
If you're writing commercial, proprietary software, then you have to pay to use Qt - but Trolltech provide a thoroughly professionally supported toolkit to you for your money.
The Qt class library is actually more akin to the standard set of Java classes than just a widget set - there's decent cross-platform support for sockets, xml, threads, unicode, etc. It really makes C++ programming very easy.
OF course, there's other cross-platform C++ tollkits like FLTK... The gui toolkit page lists many more.
Choice of masters is not freedom.
...go for Qt. Gtk, IMO, has the huge disadvantage that the current 1.2 revision doesn't support Unicode, whereas Qt fully relies on it and even provides GUI-independent helper classes for all kinds of Unicode conversion that you can use anywhere in the program. This would also help for the mathematical symbols that you probably want to display. It looks like Gtk2 will use Unicode and Pango, thus potentially blowing away the competition, but as long as there's no stable version of Gtk2, I'd go for Qt.
From a conceptual point of view, I like Gtk-- better. It actually uses the modern C++ language, including the C++ type system. This way you avoid the need for a preprocessor, and get static typechecking instead of "dynamic typechecking" (i.e. "the user does the checking"), which is the entire point of using C++ in the first place. It also use the standard C++ library instead of duplicating it poorly, so you don't have to deal with multiple string types and the like. Since the application is a GUI frontend to a library written in standard C++, using the standard C++ library classes, this matter a lot. Qt is written for an ancient subset of C++, something closer to "C with Classes" than the C++ standard.
However, Qt is simple to use, well documented, and have stable API's. In practice, these make it much easier to use than Gtk--.
As an extra plus, Qt is GPL and therefore more gnulitically correct than Gtk--, which is only LGPL.
..make your application interface independant. The idea is to make your program a basic application that can run without a gui. The gui is then a plugin or something. That way you can take one application and write a gui using gtk, QT, win32, whatever you want and never have to rewrite the application. This is how licq works. The licq application is stand alone and you can download interface plugins for it, QT plugins, gtk plugins even command line plugins. This is great for me since QT doesn't run on the platform I use, so I have to use the commandline plugin.
Don't lock yourself into one gui and hope that it will cover all the platforms you need, most of them don't. Allow any kind of gui to work with your program, not only is it more cross platform compatible, but other people can create guis for your application without ever have to touch the applications code.
Outdoor digital photography, mostly in New Engl
I regularly use the GIMP on Windows, and at least for me, it's at least as stable as any of my other Windows programs. Remember one thing: if it crashes running under *nix, people will get mad. Things aren't supposed to crash under *nix. If it crashes under Windows, people will more than likely say "humbug", restart their computer, and go on with things.
If they're redesigning the toolkit with every major release, that's a bad sign. Qt has not changed substantially since 1.x, the main difference is that functionality has been added to a rock solid infrastructure.
BTW, when is the GTK documentation going to be available ? IMO if there isn't any documentation, it doesn't even deserve to be called "1.0".
If you are developing non-GPL'd, commercial software, then the fact that you have to pay for Qt is not the worst problem.
The worst problem is that it locks you in to Trolltech as your only vendor for your UI toolkit. No one is is allowed to fork the version of Qt required for commercial apps (at the moment it happens to be the same as the open version of Qt, but there is no guarantee it will continue to be).
Being locked in like that tends to negate the whole reason for going with Linux in the first place. It not only costs you money, but it limits your freedom, and puts you back on the upgrade treadmill.
You are better to go with GTK, which is completely open source (LGPL), even if you are building commercial apps.
Or, if you prefer C++, look at using the Mozilla libraries, which have also been released under the LGPL license (as well as the MPL, and GPL licenses).
It is a officially supported first-rate platform being developed in the main Gtk+ CVS tree.
got drum'n'bass?
http://mp3.com/vitriolix
There are lots of things in the world of software development. Lots of languages, lots of miscellaneous helper tools. Lots of IDEs. I've never used automake/autoconf in my development career, and I've never needed to. Hard as it may be for you to believe, autoconf/automake familiarity is neither necessary nor sufficient to be a good software developer, in C++ or any other language.
I get the feeling you'd say that a UNIX sysadmin who wasn't familiar with (and confident enough to modify directly)Personally, I actually do think that WYSIWYG "HTML editors" have a place. I also think applications like Lyx have a place. It's just a shame that at the moment there aren't any standout contenders in the HTML side that focus on generating standards-compliant HTML (at least as far as I know, I'd be happy to be corrected on this point).
As an aside, is there any particular reason you say "my 10 year old female cousin," rather than just "my 10 year old cousin" or "a 10 year old child"? Are you trying to imply that she's doubly disadvantaged in being ten years old and female? Or perhaps even more disadvantaged in that she's your cousin?
I assume you meant to say "GUI toolkit" there... as a statement like "there's no reason to tie SQL into a database toolkit" would seem more than a little bit senseless.Hard as this (again) may be for you to believe, but Qt is not just a GUI toolkit. GUI stuff is a large part of it, but not the only part. I mentioned in another comment that I know of one app, Doxygen, that used Qt without using any of the GUI stuff - simply because the author really like the fact that it abstracted the low-level platform-specific stuff so nicely.
I love it when people say something "sucks" and offer absolutely no explanation as to why they think it sucks. Try. Come on, have a go. Tell us why the terrible Qt licensing system sucks. Lots of other people in this topic have at least made an effort (and in the process demonstrated that they don't know what they're talking about), but I'm sure you can do better than them. Um... yeah... I'd like to see you use Quake on a piece of paper.WTF are you babbling about? If you want to restrict yourself to using a text environment, do so. Nothing stopping you. Of course, if you're supposed to be developing a GUI application, you might not be able to test it at all, but I'm sure that doesn't matter for someone like you.
Gee. A whole "nickle". Thanks.Pete.