Qt is a a cross platform graphical user interface toolkit. Kuro5hin features an introductory article to Qt. On other toolkit news, GNUstep-base 1.6 was recently released.
Introduction to Qt
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Nice article (I am saying this AFTER reading it).
But oine thing I missed was any reference to KDE. Even a single line saying something similar to “KDE uses the Qt™ C++ crossplatform toolkit” would have helped..
(The “KDE uses…” is a statement from KDE.org)
A lot more applications (commercial or not) use Qt. Why a special mention to KDE was appropriate? Qt is a multi-platform toolkit, and the fact that KDE is based on Qt doesn’t change that fact…
Using your logic, should they have also listed every single project/company that uses Qt?
Why should they give any special treatment to “Open Source” projects?
no by technical superity – but by an unified approach
*nix heads never seem to understand that
“Together, we become stronger” and the best technology may not necessarily win in the market place
8-)))))
Qt is a unified approach – it allows a developer to write for almost every OS in use using a single source tree.
Oh yeah, fuck your collectivist undertones.
Euginia…lately it seems you’ve been itching for a fight, and this seems like sort of a dumb one.
Why should KDE be listed? Because it is one of the two most important graphical (Qt’s field, if I’m not mistaken) projects on Linux, and probably in the whole open source movement, maybe? Having such a huge and successful (debatable) project based on your product would look mighty good, now wouldn’t it? What a silly comment.
KDE is the single biggest project using Qt. If you’re writing a Qt tutorial, you’re probably interested in getting others to use Qt, and mentioning the big league players who use it might not be such a bad idea. It would be like Softimage writing a product blurb and not mentioning Industrial Light and Magic (they’re single biggest supporter).
Sorry, but I do not share your enthusiasm. Qt is a commercial project for the most part and while KDE *is* the biggest ‘app’ ever created with Qt, doesn’t make it justifiable to always mention KDE when you write any Qt article. Qt is a multiplatform toolkit, and if that author is using Qt just on Windows or on Mac, he doesn’t care about KDE, so he didn’t mention it. It is like saying that everytime someone is mentioning GTK+, Gnome should be mentioned as well. It doesn’t always make sense, depends on the nature of the article, and this article is nothing but an introduction to the toolkit itself.
>lately it seems you’ve been itching for a fight
This is just misconception. I just see operating systems and technologies from the 10,000 feet before I do or say anything, this is why it sounds weird to many readers on this site why I would even imagine not to include KDE in a Qt article. It is like a Greek saying: “Greece is not just Athens”. I just see things with a different eye. An eye that someone who runs OSNews and not kdenews or linux news should have: from far away, see the big picture. And while KDE is part of the picture, the big money come from the embedded market for Trolltech, not from KDE.
Can we now please go back to discussing the toolkit itself? Thank you.
We shouldn’t forget that KDE made QT become successful. Without KDE as one of the major projects using their Widgetset and without KDE as community that fixes a lot of their bugs in the code QT wouldn’t even be known. KDE should deserve to be mentioned.
Oh no, not this again. Prithee, what unified toolkit is there on Windows? Office has it’s own toolkit. Most high end apps (TrueSpace, Softimage, you name it) have their own toolkit. Most multimedia apps have their own toolkit (by the looks of it anyway) How about APIs? You’ve got Win32, MFC, WTL, OWL, and Win.Forms to list the major ones. Linux basically has two toolkits (Qt and GTK+). The fact that others exist for more specialized purposes (Motif for UNIX ported software, FLTK for super-light software) is irrelevent. This situation is almost better than OS X’s, which has two toolkits (Carbon and Cocoa) and three major look & feels (Classic, Aqua, BrushedMetal). Given the app choices out there for GNOME and KDE, it is entirely possible for me to use a single-toolkit desktop (aside from some specialized stuff like Mathematica). The minute you start up Office in Windows, or Safari you’re already heading into inconsistency city. And as Einstien said, “A foolish consistency is the hobgoblin of a small mind.”
In response to:
>Why a special mention to KDE was appropriate? (Eugina)
AND
>Using your logic, should they have also listed every single project/company that uses Qt? (John Galt)
Trolltech’s own website mentions KDE as an example for using QT.
http://www.trolltech.com/products/qt/x11.html.
(Scroll down to the bottom of the page)
So what? It is appropriate for Trolltech to show samples of their work, but that is not necessary for each and every article about Qt, the toolkit.
Personally, I don’t really care if all the apps LOOK the same (pull up Norton Anti-virus, Winamp, Opera, Trillian, etc. in Windows and see how much they resemble each other) – the important thing is, do they behave the same?
For example, in pretty much all Windows apps I use, cut/copy/paste works the same way, as do all keyboard commands – such as ALT+F4 to close. If you click on the control box, you get the same menu for pretty much every program (unless the programmers decide to add a few more options). Plus, you don’t have to worry about trying to run an app that was made for desktop enviroment A under desktop enviroment B – there’s only 1, so all apps run just the same. Plus, I don’t like the way (by default on most distros) some apps have great looking fonts out of the box, and then you fire up other apps like Xine or OO.org, and the fonts are barely readable. I mean, WTF is up with that?
I’m not going to pretend that the problems you’re talking about don’t exist. GTK+ apps do not behave as much like Qt apps as MFC apps behave like Win.Forms apps. Yes, they should unify handling of keyboard shortcuts (store user preferences in the same way). They should make cut and paste work consistently between GTK+ and QT apps (it works okay for simple text, but not anything beyond that). Distros should spend the time it takes to make all apps have nice fonts, and it would be great if they all derived their font info from the same place (which should be true soon as everyone starts using FontConfig). However, these are all interoperation issues, not fundemental problems with multiple toolkits. They can all be solved without standardizing on One True Toolkit*, like the original poster was implying.
PS*> This OneTrueToolkit thing is hilarious for another reason. What happens when the OneTrueToolkit 2.0 comes out? The Mac, for example, subscribed to the “One True Toolkit” model, and now they’ve got 3 to deal with. Here, users of OSS software have an advantage. KDE has gone through 3 major, incompatible revisions. Yet, pretty much every KDE app is available in a KDE 3.x version. Why? No closed binary-only software. Moving apps to the latest version was a matter of some simple porting and a recompile. No waiting for developers to release new versions (like Mac people are having to do with Quark). Even when Win.Forms comes out (in 2003, more than a decade after the initial introduction of Win32), do you think any single Windows desktop will be free of crufty “classic Win32” based apps?
windows programming, for the most part, is about mfc and VB
few windows apps are done in straight win32 and wtl is just mfc minus some bloated doc/view features
then in vs.net wtl and mfc are “merged” again
to type a http link using the keyboard
IE CTRL+O as “always”
Opera F8
Netscape/mozilla CTRL+SHIFT+L
Are there any screen shots of GNUStep around? I tried to find some on their website, I was out of luck.
Hey Alex, here are some: http://gnustep.org/experience/images/Gorm-Example1.jpg (Gorm, the interface builder), http://gnustep.org/experience/images/ProjectCenter-0.27.png (Project Center, the IDE), http://gnustep.org/images/GWorkspace.jpg (GWorkspace, the workspace manager) http://gnustep.org/images/GNUMail.jpg (GNUMail, I bet you can guess what this app does
), http://www.nice.ch/~phip/images/ImageViewer.jpg, http://www.gnustep.it/nicola/Applications/Gomoku/GomokuSS.png (game 
). IMO the look of the widgets is ugly, but the API (if you can call it that) is supposed to be really great.
Wowww
) Thank you so much for the links Sonarman! I don’t know what to say, how I missed them when I went to their site.
I work on scientific applications built around Qt and have been recently working on some very computationally intensive work.
Sadly the builtin Qt collections are entirely built for convenience sake, but they totally fail for efficiency. I’ve actually dropped using their collections and have started entirely using STL for all my data structures and collections.
STL is nice in that it doesn’t give you the ability to use inefficient accessors (ie, no operator[] for linked list) and the stl collections also scale much much better, I noticed (after some testing) the operations for some of the QT collections become much slower the more data they hold.
I almost wish they would depricate their own data structures and just use STL at this point. Reimplementing what’s already there and works better doesn’t make a whole lot of sense.
I’ve been trying out various widget sets for hobby projects, wanting to write on Windows myself but be able to have Linux users too etc.
I’ve tried wxWindows, FLTK, FOX etc. Even OpenGL ones. All my Qt is on Linux, but I’ve looked at that too.
And they all find ways to write around a fundemental disadvantage of the C++ language – the lack of function callbacks on class instances.
In Delphi etc listeners can be “of class” which works like a normal function callback but can go straight to an instance of a class. Very neat code. If you are a super programmer, you can of course reassign these listener callbacks at runtime.
Whereas the various C++ toolkits have various ways of coping with this omission. Some use subclassing of the widgets. Some have very visible message maps and bunches of constants to cope with and confuse. Others have static callbacks and ids being passed around. All very very messy.
What is the best C++ way to make event-driven code?
Either use Qt’s signal/slot system or the IMHO better libsigc++ which is also used by gtkmm. Anyway they both share quite the same logic. Member function callbacks are no problem and in the case of libsigc++ there is even static typesafety guaranteed. Also you don’t depend on the huge libqt.
Regards.
> What is the best C++ way to make event-driven code?
libsigc++, as used by gtkmm:
http://libsigc.sourceforge.net/
What is the best C++ way to make event-driven code?
Qt’s signal/slot mechanism is very nice and easy to use, if you don’t mind the extra pre-processor step (which is quite painless if you use qmake). BeOS’s system of BMessages, BHandlers, BLoopers, and BMessengers works well also (although you have to write the BMessage construction and examination code yourself).
There was some discussion on the Qt mailing list regarding using templates to achieve functionality equivalent to Qt’s signal/slot mechanism without the need for a moc-style preprocessor. Assuming that is possible, that might be a good way to go.
“We shouldn’t forget that KDE made QT become successful.”
Yes, KDE developers have found many bugs and shortcommings of Qt which got fixed. KDE helped Qt as Qt has helped KDE.
BTW, here are some video demos from Trolltech: http://www.trolltech.com/video/index.html?cid=1
They give a short introduction into Qt. I wonder why they haven’t been linked in the article.
“I almost wish they would depricate their own data structures and just use STL at this point.”
Take strings for example. STL strings do not support unicode. Qt strings do (and unicode is something you need dearly in UI’s these days). Thus it would be a bad idea to drop Qt data structures. Also STL programming style is not like Qt programming. It would introduce many inconsistencies. Better file a bug report for the inefficient algorithms in Qt and get them fixed. It happend before and can happen again. Just inform the developers about it.
Or so I hope it is. It looks good, is elegant, and objective c is superior to c++.
QT is just crap, imo. GTK is nice. But GNUStep and OpenStep has a larger future than most think imo.
I agree, objective c is nice, the api is very nice and all that. (I’m currently learning cocoa) But gnustep doesn’t *look* attractive. Yeah, that’s irrelevant from a technical point of stance. But compare it with beautiful girl vs ugly girl. Even tough it is very well possible that that ugly girl has more “content”, people will pay more attention to the beautifull girl.
Unfair, but that’s how it goes. Now I don’t want a gnustep that is yet another windows or macosx clone. Gnusteps tearable menus are a great ui feature for example. But the squareness and dark colors could/should be changed.
@Nice: Actually, C++ has very good support for callbacks. The main reason Qt rolls its own is that until recently (we’re talking Visual C++ 6.0 here) you couldn’t count on portable code being able to use advanced C++ features like templates, because compilers didn’t support them uniformly. Today, if you’re coding for modern compilers (Visual C++ 7.1 and GCC 3.x and up) and need a signaling mechanism, the definate way to go is to use Boost.Signal (see http://www.boost.org). For those who don’t know about it, the Boost libraries offer a lot of extended functionality beyond that available in the C++ Standard Library, while being very portable, and keeping the same style and conventions as the standard library. It offers support for everything from unit testing to multithreading, are extremely general purpose (thanks to the magic of templates) and are very well documented.
@Andreas: I definately think that Qt should deprecate as much of their collections library as they can get away with. The days of rolling your own collections are over for C++. The STL is extremely fast, expressive, and the bedrock on which modern C++ libraries (like Boost) will be built. Unless there are specific reasons to hold back (the unicode thing might be one) Qt should go with the flow and “standardize” their library. It’s been five years since ISO C++ 1998, and I have yet to see a major platform that uses “modern C++” (rather than the vanilla-OOP subset of C++).
It’s not *that* ugly. The original OPENSTEP (the OS) was really quite beautiful: sure it looked grey and ‘ugly’ but the attention to graphical detail and the work into the icons and the refined and consistent look and feel and means of interaction with the operating system were Just Right.
Hopefully GNUstep will be able to in the end bring a similar free implementation of this to the end user. Right now things seem to be a tad rough.
I was careful to state the feature I like that makes attaching events to actions very neat code – class method callbacks. This means that the OnButtonClick() might be in the parent form and not in the button, and that the button need not be subclassed. You can add all kinds of components to a form at runtime and assign the event callback completely dynamically.
Templates are kind of cool, but it is making all your decisions at compile-time.
Qt uses a preprocessor to hide the complexities of the spagetti code that is required to do easy-to-program event handling code.
Method callbacks would be useful in other C++ situations too: have you ever shaked your head at having a static method with an instance parameter to call a class method in a class so you can do << >> operator overloading or something?
But then if I was trying to rewrite C++, I’d be looking for functions within functions (GCC has them extra for C, but not C++) etc etc etc
STL does have support for unicode, with the wstring class. As you may know, an STL string is defined as
typedef basic_string<char> string;
while the wstring is
typedef basic_string<wchar_t> wstring;
were wchar_t, while implementation specific, is big enough to hold an UTF-16 character.
So, QT could just add use basic_string in its classes, to have instant support for the STL string.
I think the main functionality of the preprocessor is to give a reflective infrastructure to a language which doesn’t have any (I’m not counting RTTI support, which is kinda limited). You may say that the preprocessor makes C++ more similar to Java and Smalltalk 😉
From this point of view, making all the decision at compile-time (with the templates) is more ‘C++-esque’.
I didn’t knew about wstring and wchar_t. Thanks for the info. I suppose it’s time to update my STL knowledge.
There seems to be a fork brewing in XFree, Keith Packard has had his core membership removed,
“It has been brought to the attention of the XFree86 Core Team that one
of its members, Keith Packard, has been actively (but privately) seeking
out support for a fork of XFree86 that would be led by himself. He is
also in the process of forming a by-invitation-only group of vested
interests to discuss privately concerns he has about XFree86 and the
future of X. He has consistently refused to even disclose these concerns
within the context of the XFree86 Core Team, which makes his membership
of that team unviable. As a consequence, Keith Packard is no longer a
member of the XFree86 Core Team.”
see the full post at
http://www.xfree86.org/pipermail/forum/2003-March/000001.html
Yes, GNUStep is the future. And it will always be.
I still remember in 1996, when people said “why work on KDE if GNUStep will be ready soon” 😉
Or even better:
Why work on Linux when the Hurd will be ready soon 🙂
Hurd isn’t interesting until they get it ported to L4. Until then there’s no hope of them even coming close to linux’s performance. How did this fork start??
“5 years from now everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5”
And yes, he did say that: http://www.dina.dk/~abraham/Linus_vs_Tanenbaum.html 😉
I still remember in 1996, when people said “why work on KDE if GNUStep will be ready soon” 😉
Well, the problem is that there aren’t many people working on GNUstep. So things progress slowly. Another big thing is that with KDE, they started with an already existant GUI library (Qt) and thus they were able to quickly “show” something to potential users/developers. And Qt is a really good C++ library (with signals/slots paradigm).On the contrary, until quite recently, GNUstep’s gui wasn’t very stable or finished …
That said, GNUstep, as a programming framework, is useable NOW. More people are coming, in part due to the publicity done on OpenStep/ObjectiveC with Apple. So, as the OpenStep framework is a really good one (imho, one of the better, if not the best), and ObjectiveC is really good in programming GUI applications (due to its dynamic nature), along with the existence of GUI builders such as Gorm, I hope more and more people will use it. Frankly, you should take a look on it, it’s really interessting, very well designed.
Take a look on some articles/tutorials here : http://www.roard.com/docs/
I wrote an introduction article to GNUstep (with Fabien Vallon), it’s available here : http://www.roard.com/docs/lmf1.article/
For the comments about the look of the GNUstep’s gui, It’s *possible* to change it, but nothing is realeased so far (I’m busy and I didn’t worked on it since some times, but you could look some screenshots here : http://www.roard.com/screenshots/screenshot_theme19.png and http://www.roard.com/screenshots/screenshot_theme20.png , just to show you that’s possible
Why does this guy write of GTK+ because it’s written in C? From what I’ve read, it seems GTKmm is more C++ish than Qt any day. Bizarre attitude.
I should also add someting : one of the big difference with KDE/GNOME and GNUstep, is that GNUstep is reimplementing an existing framework. It explains why it had taken so much time to “show” something with GNUstep’s framework (and thus attract developers), as near everything needed to be implemented.
KDE/GNOME on the contrary did produce things faster. But they also needed to evolve (KDE1=>KDE2=>KDE3, same for GNOME …) … GNUstep has one thing for it, it’s absolutely stable for its API.
The OpenStep API was published in 1994, and didn’t change since ! it’s the same API on MacOS X (they just added some widgets, but that’s all). The fact that nothing evolved in nearly 10 years (an incredible time in IT market) is a good indicator of the quality of the OpenStep framework …
Another Big plus for GNUstep is the goal of the project : the portability. Currently, it runs mostly on Unices, but alpha port exist on Windows (see http://www.roard.com/screenshots/gnustep_on_windows1.jpeg , http://www.roard.com/screenshots/gnustep_on_windows2.jpeg ,
http://www.roard.com/screenshots/gnustep_on_windows3.jpeg) and there is even some basic works done on BeOS
gtkmm might be more C++’ish alright, but i can’t see why i should really care.
What i look at is which API lets me get the work done easiest. And here i don’t just mean which is the easiest to learn, but which is easiest to work with, require less code, has a readable syntax, makes it easiest to avoid errors, etc.
Last time i tried gtkmm (its been quite a while, so i will apologize in advance in case things have changed radically) i found it fairly cumbersome, and often overcomplicated.
In comparison i find QT is elegant and easy to understand, and i especially like their signal/slot mechanism.
Sure they introduce an extra preprocessor, but i can’t see why this is a problem.
And finally, i think many C++ programmers still prefers writing KDE programs instead of Gnome programs, not because QT is better than gtkmm (for all that i know, gtkmm might be very good), but because all of QT and KDE is written in C++. Why does this matter? Well, i don’t except i’m the only persons out there who have read some of the code in both QT and kdelibs, and some kde programs. I much prefer reading C++ programs to C programs. This was ultimately what moved me from being a gnome user to a kde user. Had all of gnome been written in gtkmm, then i might still have run it.
I’m sure some people run Gnome because they don’t want to touch C++ code, even if they can get C bindings for QT and KDE.
So QT and KDE programming sure is C++ish enough for me.
What about GNUstep source-OPENSTEP porting?
Well, as for a MacOS X port, you need to redo the nibs using Gorm (nibs are binary, the format is unknown to be short), and redo a Makefile (btw, GNUstep’s makefiles are really, really nice), but that’s all. It should be even easier than a MacOS X port, as some new widgets (NSDrawers …) added by MacOS X aren’t yet fully supported on GNUstep (but all the OpenStep one are).