Trolltech made available online an article from their print publication “QT Quarterly” (usually only made available to Trolltech customers only) previewing the new features, optimizations, and improvments that QT 4 will have to offer.Of interest is a new widget painting engine called Arthur which supports a large variety of display systems, and eventually can support the Cairo graphics API. In addition a number of big performance improvements can be expected. The end of the article mentions that a technology preview for QT 4 will be availalbe this summer, with a beta release scheduled for the fall. Credit for this story goes to KDE dot News.
Preview of QT 4
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Is it sad that I’m giddily excited about a GUI toolkit? Qt4 looks absolutely awesome. It looks like Qt4 will help Linux GUIs keep pace, technologically, with the advances in Longhorn. It looks like some of this stuff (eg: Interview) won’t even be in Longhorn. A solid Qt4 release by 2005 could give Linux GUIs a very solid, technically, platform to build upon in competition with Longhorn.
quote from that site:
“The new model/view framework, codenamed Interview, provides tree views, list/icon views, and tables using a common data model abstraction to support data-driven GUIs that are fast and responsive even with large data sets. ”
This is exactly what I’m looking for.
When dealing with a lot of data, current programs tend to be rather slow (on my pc, which is an old Pentium II). This will probably solve it.
The improvements sound great.
Many of the problems I’ve encountered with Qt 3, such as when I need to invoke the slots associated with a signal from a different thread (i.e. from the parent thread, which is handling GUI events), required me to send an event to a QObject to get across the thread boundary, then have a handler for that event which would invoke the slots for a given signal. Qt 4 moves away from this, and finally threads integration should be much more cohesive.
I just hope they work much harder on the look in OS X… it was somewhat mediocre in Qt 3
May be QT 4 introduces it.
That would mean one can use <shift>-key and all these special features in apps like konqueror. Selecting multiple files in a standard way and that only 6 or 7 years after KDE’s 1.0 release? Impressive.
let’s wait another 10 years and KDE users can get rid of the menu editor. Unbelievable possibilities for the Linux desktop.
I hope Qt4 don’t use the moc precompiler. C++ is now mature and the use of templates, namespaces, STL, etc is stable by now.
I hope also that IBM or another company buy Trolltech and give a more friendly licence for Qt, like LGPL or BSD for all platforms (including Windows). It would represent a large incentive to use Qt as the universal and free C++ toolkit for every platforms.
Could you give a bit more detail on what you’re talking about? Shift and whatnot work fine in Konqueror for me. Or am I misunderstanding what you mean by shift behavior?
Shift doesn’t work as expected in konquerors multi-column view.
Try it with using SHIFT for selecting multiple files.
Keyboard in general doesn’t work as expected in konquerors Multi-Colum view, try it out with the arrow keys.
These bugs survived 7 years of KDE. The user base seems to be very small.
Actually, the power of moc appears to have been expanded in Qt4. This is a good thing, and is done with good reason.
Yes, the STL and templates are stable in C++. They are also wholly inappropriate for GUI code. The STL is aggresively static, and static languages suck for GUIs. Take a look at the foreach example in the article. That’s precisely what is wrong with C++ for code that would be better handled dynamically. GUIs are inherently object-oriented, with reference semantics and polymorphic types being much more natural than the value semantics and static types the STL/template mechanism encourages.
What do you mean by “expected?” The behavior doesn’t seem that unusual to me, though, I can’t even remember how Windows does it to tell the truth. If the behavior is buggy, then its probably a sign that nobody uses the shift key to highlight. Have you posted to bugs.kde.org?
Also, don’t forget that APIs that use templates extensively look, at the link level, like the compiler threw up. This makes them exceedingly difficult to wrap for other languages.
Qt 4 introduces a new set of template classes, codenamed Tulip, that are lighter, safer, and easier to use than the STL’s containers. Developers who are unfamilar with the STL, or who prefer the “Qt way” of doing things, can use these new classes instead of the STL classes.
Standards, sTandards, stAndards…
I dunno. That meta-object compiler is central to what they do. The fact that there are boost libraries that offer similar functionality would, one hopes, one day lead to a more standardized Qt. I seem way in the minority on the point, though.
This soudns great, I can’t believe Qt is getting so fast. Qt4 might actually be faster than FLTK!
keyboarder, I can’t seem to verify what you’r talking about on KDE 3.2.2 Debian either. It works exactly as expected.
Give me a link to the bug report, maybe I’ll understand this.
Also Qt 3.3 and I think 3.2 also call the native Mac APIs to draw the interface so the style is like in any other application. Even if apple cahnges the style, the function/class names will remain the same and Qt will continue to draw a native interface.
QT4 wont help linux to keep pace with longhorn.
QT4 will beat longhorn.
linux has come a long way
people used to compare it to the current windows, now they compare it to the windows that wont be released for atleast 3 years (more likely 4-5)
>> A new docking architecture
Hmmmm, hopefully this will remove all those ugly and redundant lines between different parts of most applications user interfaces.
This could really make things look much more professional (visually).
From an interview with Matthias Ettrich:
[snip]
PF: Eugenia Loli-Queru (from OSNews) has been complaining in an article than on Mac OS, Qt applications are not perfectly like the Aqua applications. The complaint is that Qt is actually emulating the first version of the Aqua style, and Apple has since then slightly changed the style. So you are not using native Mac OS X API, unlike the Windows XP version of Qt. Is that correct?
EE: Yes and No. The very first version of Qt for Macintosh, the 3.1 version was emulating the style. It was the first Aqua style and it has changed a bit.
The current version (3.2), and the one in GPL, is actually using Apple’s style API to draw widgets. That means that we follow whatever changes Apple does to the style and that Qt stays up-to-date.
So there is no reason to complain about that anymore.
[snip]
http://dot.kde.org/1081772638/
may i ask what you have against the GPL? yes its under the GPL for non profit use. if you want to make something and sell it then well you have to talk to trolltech about buying a licence as they are a company after all, not a fundation or anything like that…
Selecting files in multi-column view worked as expected here. What can’t you do, specifically?
Relevant package:
kdebase-3.2.1-7mdk
Alex
KDE 3.2.2 is out?
It serves both free software and commercial purposes. You want to realease a great GPL app with QT? Fine, use the GPL version. You want to use a solid toolkit, with loads of options, to make a proprietary product which you intend to sell under a non-free license? Fine, but you have to compensate the folks who provide you with this fine software.
And, let’s not forget, QT is a multi-platform toolkit, which is a definite advantage over some of its competitors.
“Alex
KDE 3.2.2 is out?”
yeah, it is on debian and in CVS
>Yes, the STL and templates are stable in C++. They are also >wholly inappropriate for GUI code. The STL is aggresively >static, and static languages suck for GUIs. Take a look at >the foreach example in the article. That’s precisely what is >wrong with C++ for code that would be better handled >dynamically. GUIs are inherently object-oriented, with >reference semantics and polymorphic types being much more >natural than the value semantics and static types the >STL/template mechanism encourages.
You can call polymorphic functions from std::for_each.
For those of you throwing FUD around MOC without understanding its true power… go read what the GNOME guys are now saying about GObject introspection. They’re now thinking of adopting MOC to GNOME/GTK.
QT4 wont help linux to keep pace with longhorn.
QT4 will beat longhorn.
linux has come a long way
people used to compare it to the current windows, now they compare it to the windows that wont be released for atleast 3 years (more likely 4-5)
Then again, the big winners of Longhorn will be the developers. If they pull it off, and create a nice API that doesn’t leave programmers running from the room screaming, then you’ll find that there will be a greater adoption.
Then again, that is *assuming* that the world stays static, the fact is, if Linux delivers a better API, wine catches up (which it has) then programmers are going to say, “why the heck not develop for Linux?”, “why not work with SUN on creating a Linux version for their version of JDS?”.
You can do polymorphism in std::for_each, but only very painfully. Basically, the problem is that the STL works on value semantics. Ergo, if you want polymorphism, you have to store pointers in the containers. Now, that defeats the inherent memory allocation advantages (namely, the programmer doesn’t have to do any) of the STL. So you have to store smart pointers in the containers. That means a couple of things:
1) Looping becomes a horrendous pain. You either live with insane, multi-line for() declarations, or litter your code with typedefs the compiler should be able to figure out for its own damn self. You can use for_each, but since C++ lacks lambdas, that’s also a pain. You can use Boost::Lambda, but that’s phenomenally error-prone, and compile errors resulting from it are nearly impossible to debug, due to the complex template expansion.
2) You have to deal with the fact that you’re not storing pointers in the container anymore. This means that for every API that uses regular pointers, you have to wrap/unwrap the pointer in places.
These are just some of the problems. The problems with the STL and the template mechanism for polymorphic code are extensive and run deep. That’s to be expected — Andrew Stepanov, the principle designer of the STL, has said: “I think that object orientedness is almost as much of a hoax as ArtificialIntelligence.” This reflects in the design of the STL.
I like standard C++, and love the STL. I’ve used it to great effect on a number of numerics projects, and it worked wonderfully. But its just not appropriate for situations where OOP is warrented. That’s okay. C++ is a multi-paradigm language. You’re supposed to use what techniques work best in a given situation — not force everything to fit one paradigm (*cough* Java *cough*).
@Chris: It’d be nice to use the STL and Boost if they did the same things as Moc does. But they don’t. Not only do they have a completely different programming model, but have a burdensome syntax, and can’t do things like properties, reflection, etc, which the Qt model supports via moc.
But it has its own quirks.
Check this out:
http://freedesktop.org/pipermail/dbus/2004-March/000884.html
Magic comments that change the IDL-generated code? Ermmm… moc is GORGEOUS compared to that (although they are meant for different things, really)
In terms of API, it appears that what Linux is doing is moving beyond what Windows will support in Longhorn. Consider: WinFX will be the first Windows toolkit to offer a layout manager. Qt and GTK have had them forever. Now that WinFX is getting it, Qt is going further with, for example, Interviews. Its going to be very competitive, no doubt, but right now, Linux’s API still have a bit of an edge, and it looks like that trend will continue for the next few years.
Still can’t get a free/cheap Windows license though, and the Linux/Mac licenses are not even GPL, so it’s still inferior to wxWidgets.
Mac licenses are GPL’ed.
I’m sorry I disagree strongly.
You can do polymorphism in std::for_each, but only very painfully. Basically, the problem is that the STL works on value semantics. Ergo, if you want polymorphism, you have to store pointers in the containers. Now, that defeats the inherent memory allocation advantages (namely, the programmer doesn’t have to do any) of the STL.
How is using pointers in containers so painful?
Yes you have to manage memory, but is that really so hard?
Sometimes it is better to use pointers for performance reasons.
So you have to store smart pointers in the containers. That means a couple of things:
Only if you are determined not to manage memory
1) Looping becomes a horrendous pain. You either live with insane, multi-line for() declarations, or litter your code with typedefs the compiler should be able to figure out for its own damn self. You can use for_each, but since C++ lacks lambdas, that’s also a pain. You can use Boost::Lambda, but that’s phenomenally error-prone, and compile errors resulting from it are nearly impossible to debug, due to the complex template expansion.
Boost::lambda is easy to use once you understand the notation, it makes writing functors easyer, not harder.
It’s just a matter of getting your head around something new.
2) You have to deal with the fact that you’re not storing pointers in the container anymore. This means that for every API that uses regular pointers, you have to wrap/unwrap the pointer in places.
Based on the (incorrect) assertion that smart pointers are your only option.
These are just some of the problems. The problems with the STL and the template mechanism for polymorphic code are extensive and run deep. That’s to be expected — Andrew Stepanov, the principle designer of the STL, has said: “I think that object orientedness is almost as much of a hoax as ArtificialIntelligence.” This reflects in the design of the STL.
Andrew??
You are right about C++ not being the language of choice for everything. But you make some rather misinformed assertions about pointers, containers, and boost::lambda.
People use STL containers and pointers all the time, sometimes you don’t want to encure the performance hit of copying the object in the container.
Lambda does have problems with other things (function overloading for instance), but I have run into no problems using it with pointers.
How is using pointers in containers so painful?
It greatly complicates the semantics of what’s going on. Instead of just dealing with object references, you have to be aware of the pointer, the pointed to object, and (when dealing with iterators) a double-indirect pointer to an object. Fugly…
Yes you have to manage memory, but is that really so hard?
Manual memory management is a thing of the past. The cool thing about modern C++ design techniques is that smart pointers and the STL containers is that you don’t have do manual memory management anymore. Using raw pointers in STL containers gets rid of that advantage.
Sometimes it is better to use pointers for performance reasons.
Yes it is, especially on the P4 which is very good at handling indirect data. However, Qt’s containers use pointers too — because they have reference semantics by default. The difference is that they do that under the hood — you have a list of QWidgets, not a list of pointers to QWidgets.
Only if you are determined not to manage memory
Yep. I’m determined to listen to all the modern C++ design books and let smart pointers manage memory.
Boost::lambda is easy to use once you understand the notation, it makes writing functors easyer, not harder.
Boost::lambda is not easy to use. It doesn’t handle regular C++ code, but something that looks very similar. You have to pay close attention to make sure you’re not breaking the mechanism. Right from the introductory examples of Boost.Lambda:
“Note that a normal (non-lambda) expression as subexpression of a lambda expression is evaluated immediately. This may cause surprises. For instance, if the previous example is rewritten as
for_each(vp.begin(), vp.end(), cout << ‘
‘ << *_1);”
I’m sorry, but I’ve got better things to do than deal with subtle corner cases in a language that is already full of them. And I have no patience to deal with compile errors that are a dozens of lines long for a simple error in a lambda expression, especially when no C++ IDEs will show you what the heck a template call expands to.
It’s just a matter of getting your head around something new.
Oh, its nothing new. I’m very familiar with lambdas, in a number of languages. Boost.Lambda is by far the most cheesy, limited, and least useful. For god’s sake, you can’t even store a lambda in a variable! Not to slight the Boost developers (Boost as a whole is a great library), but Boost.Lambda is over the edge of what is reasonably possible within the limits of C++.
Based on the (incorrect) assertion that smart pointers are your only option.
If you want to go back to debugging memory errors, fine. I’ve got better things to do, and I’m glad the Trolltech guys realize that. Its bad enough that C++ doesn’t have a GC, but throwing away the only comparable techniques C++ does have (smart pointers and value-oriented programming) is just stupid.
Andrew??
Got my C++ luminaries mixed up. Its Alexander Stepanov and Andrew Koenig. Andrei Alexandrescu just complicates things further… But the point remains that the guy who designed the STL thinks that object-oriented programming is a hoax, and that reflects in the design of the STL.
People use STL containers and pointers all the time,
And they give up one the prime advantages of the STL in the process. Look through the comp.std.c++ histories. You’ll see several objectors to the STL-way of doing certain things.
sometimes you don’t want to encure the performance hit of copying the object in the container.
Blame that C++’s weak memory model cannot support a proper optimizing compiler that’d handle low-level details like that. But that’s another diatribe…
Lambda does have problems with other things (function overloading for instance), but I have run into no problems using it with pointers.
I’m not saying that lambdas have problems with pointers, I’m saying that using pointers makes you give up many of the advantages of the STL, and that lambdas are impractical to use at any scale.
With the greatest respect, I must ask, do you write commercial code?
In the real world one is constantly dealing with ‘corner’ cases. I write code for a Telephony company, one of thier server applications is a message router.
Basically the code involves recieving a message, finding the given client, and routing the message.
There are 1000’s of clients, and they are constantly connecting and disconnecting, message flows in the 10’s of thousands every second have to be sustained.
In the center of the application lies the contianer
std::map std::string /*client name*/ to Client*.
The original version of this application did not do memory management of this map, and was slower than the original Visual Basic version.Not good, by managing pointers in certain places I was able to get vast speed increases.
Should I have told my boss too make sure all his clients had P4’s, I don’t think that would have gone down very well.
You argument againest performance is very ‘Java’ esque, in the real world, it has to run fast, or clients are unhappy.
Sure you don’t manage anymore memory than you have to, but sometimes you simply have no choice.
It’s easy to make blanket statements like ‘lambda is bad’ and ‘I’m not going to manage any memory’, but in reality these things happen all the time.
With the greatest respect, I must ask, do you write commercial code?
Kinda, but its closer to research than end-user stuff.
The original version of this application did not do memory management of this map
How did you do “memory management of this map?” I don’t see how using smart pointers rather than regular pointers would be a huge performance impact here, unless you did insertions very often, where the overhead of copying the smart pointer and twiddling the reference counts comes into play.
You argument againest performance is very ‘Java’ esque, in the real world, it has to run fast, or clients are unhappy.
Oh, please. Java is a straw-man example. It doesn’t have particularly good performance characteristics. There are lots of real performance sensitive apps written in GC’ed languages.
Sure you don’t manage anymore memory than you have to, but sometimes you simply have no choice.
In most cases, a GC will be (amortized) as fast as malloc(). If its not, you can usually adjust your code so it will. There are cases where the GC just won’t work, but good GC’ed languages give you the ability to either disable the GC and do your own memory management, or use special allocation strategies. GC’s like the Memory Pool System have multiple pools each with their own strategy. If allocating certain objects is killing the GC, you can change your code slightly to tell the GC to allocate those from an un-gc’ed heap. However, the fact remains that we’re talking about Qt, and there is not a GUI app in existance where the overhead of using smart pointers in the app->toolkit interface comes into play.
“and the Linux/Mac licenses are not even GPL, so it’s still inferior to wxWidgets.”
Uh, Qt’s Linux-license is most definitely GPL!
The map got a hammering, insertions, deletions, etc.
The map was composite in a larger object, which simply allocated the object on insertion and deleted it when an element was erased. Entry points were well defined so the memory stuff was simple.
Oh, please. Java is a straw-man example. It doesn’t have particularly good performance characteristics. There are lots of real performance sensitive apps written in GC’ed languages.
Java is the real world, I hate it, but it’s there. So therefore it’s not a ‘straw man example’.
You can dance around the point if you like, but ‘throwing more hardware at it’ is not a solution in the real world.
I don’t fully understand you last paragraph, something about GC being as fast as manuel memory managment, it sounds like you have done a university course on the subject.
All that counts in the end is subjective user experience, and that is a combination of speed, stabilty, and design.
One has to know algorithm basics (O(n) vs O(log(n))) so as to write bad code. One must be aware of the limits of the tools
But I’m more interested in making money than mathematical models.
And that I fear, is where we differ.
I can’t select multiple files with shift key:
Example: you have columns in the file view/dialog like this:
a d
b e
c f
c1 g
c2
It’s impossible to select files b to e (incl. c..d) in a standard way (shift).
Navigation with arroy keys is also buggy and leads to strange behaviour.
These are bugs in the QT libraries.
Try Microsoft’s Explorer’s multi-column-view and see how it should be (select b, navigate to e, press shift and click).
Working keyboard support is an essential feature.
well, i’m using Konqueror on MDK 10.0.
and actually shift+select won’t work, when selecting many individual files.
But CTRL + select works…
QT looks like a very nice toolkit, but unfortunately I can’t touch it. As far as I can tell, it would be illegal for me to write QT-based software using my favorite license, the BSD license. Well, I guess I could if I purchased a QT license, or decided not to release any binaries.
For people saying that the GPL is not a big issue keeping people away from QT, I would have to disagree. Open Source != GPL. There are a world of open source licenses out there and to my knowledge only the (L)GPL is 100% compatible with the GPL. Yes, I know, this is by design, but it still sucks. Trolltech should at least make an exemption for using QT with BSD and MIT-style licenses. It’s not like I’m trying to make a free buck off of QT.
especially the new Qt4 painter sounds cool, very promising
Ctrl is for selecting individual files. Works!
Shift is for selecting a range of files. Works, but not as expected.
Arrow keys are for navigating through file columns. Works, but buggy.
what would be nescesary to keep up with longhorn would not be qt4 it would be a complete, modern, hardware-acellerated replacement of the x server. of course even to keep up with windows 98 that would be the case, grafic wise. but obviously people don’t mind that x suck. so what? qt4 isn’t even relevant to any linux user, exept of course those using kde.
“Trolltech should at least make an exemption for using QT with BSD and MIT-style licenses. It’s not like I’m trying to make a free buck off of QT”
Then everyone would use it, depriving TT of income. Or, at least tey would claim to use it. If someone wrote proprietary apps with Qt without paying TT; they could just claim that they were using the BSD-licensed version of Qt. And it would get confusing trying to determine who uses GPL’ed version and who’s using BSD-version and who uses the commercial version. And why would anyone use the commercial version anymore?. With the current setup it’s really simple: If you write proprietary apps, you have to pay. If you write Free apps, you don’t have to pay. It really couldn’t be simpler.
You might not want to exploit TT and their work. But you can bet your hiney that there are lots and lots of people/compnaies that would do just that.
No, Qt or it’s license is not a problem. No-one is forcing anyone to use Qt. And even if Qt became THE toolkit, there’s nothing really stopping people from using some other toolkit. Only way Qt would gain complete dominance would be if developers choose to use it. And, believe it or not, many of the care about more things besides price. They don’t have any problems shelling out few bucks for quality tools.
As far as I can tell, it would be illegal for me to write QT-based software using my favorite license, the BSD license.
Yes you can:
http://www.trolltech.com/developer/faqs/free.html#q15
Thanks for the link!
Now if only Trolltech would release a free Windows version. Oh well, such is life. At least now I can put QT back into consideration for my projects. Thanks a lot.
Oh, and in response to Janne, I wasn’t saying QT should be released under the BSD license, I was saying they should exempt the BSD license, which appears to be what they have done. I am all for companies making money and allowing programmers to feed themselves.
I’m not knocking the quality of the product, but the degree of isolation and lock-in is enough to make MS proud.
They have created there own variant of C++, and even now that C++ has matured and standardized, they continue to work against it. I can go to a dedicated Windows C++ site, like CodeProject, and find tons of code that will work anywhere. But I can’t share anything with a Qt developer, especially with their new Qt4 container classes.
wxWindows is similar but only for historical reasons, and they are now moving their container classes towards compatibility with the STL.
Again, I’m not knocking the technical quality of Qt4’s new container classes, but I thought that the open source community cared at least a little bit about standards?
They do care about standards! Just not standards interoperability. That’s why I can’t place a symlink in one place and have it show up on KDE and Gnome desktops, why I can’t place another symlink somewhere else to have a program start up with KDE and Gnome, why copy & paste “mostly” works, etc etc.
The map got a hammering, insertions, deletions, etc.
The map was composite in a larger object, which simply allocated the object on insertion and deleted it when an element was erased. Entry points were well defined so the memory stuff was simple.
If the map was getting so hammered, why didn’t you just allocate the elements from a pool? Routing table entries would probably be a fixed-size, so pool-allocation would be great for this. Then, you could write a smart-pointer template that would do the memory-management under the hood. If you’re doing all those allocs/frees anyway, the overhead of copying the smart pointer is trivial.
I just don’t get your argument. If you’re saying that this is a case where you should use a pointer in an STL container, then I agree with you. However, I wasn’t saying that you should always use value-types in STL containers. I’m saying that the STL is not useful sometimes because in order to conveniently use reference types, you have to give up the memory-management benefits. It actually sounds like Qt’s containers would be perfect for this task! And that’s precisely my point — there are other tools better suited to certain problems than the STL is, and code that needs reference semantics is one of them.
Java is the real world, I hate it, but it’s there. So therefore it’s not a ‘straw man example’.
Sure it is. Weaknesses in Java are a reason not to use Java, not a reason not to use GC’ed languages in general!
You can dance around the point if you like, but ‘throwing more hardware at it’ is not a solution in the real world.
When did I say that ‘throwing more hardware at it’ is a solution? A good GC, however, *is* a solution. Java 1.4.x has a pretty good GC, but its rather unflexible. There are other GC’s that give you the performance/usability benefits of the GC, but let you drop down to other allocation strategies when necessary.
I don’t fully understand you last paragraph, something about GC being as fast as manuel memory managment, it sounds like you have done a university course on the subject.
I’ve never taken a university course in CS. But it looks like it wouldn’t hurt you to crack a book on the subject… Yes, GC’s can be as fast, or in some cases, faster, than manual memory management. Take, for example, cases where you are creating and deleting lots of temporary objects. A generational GC is *perfect* for this sort of use. Allocation involves little more than incrementing a pointer, while deallocation involves a single GC that cleans the youngest generation in one operation. This will be faster than nearly any manual memory management scheme — even pool allocators need to do (relatively slow) list manipulations on allocation/free. I’m curious — ever try to write a high-performance malloc()? If you did, you’d easily see why GC could be faster in many cases — malloc() is *expensive*.
But I’m more interested in making money than mathematical models.
Is there a point to this sentence?
There is no point in using a standard that doesn’t do what you need. I think I missed the memo where Bjarne said that C++ programmers now have to be the bizarre sort of ideological conformists so many Java programmers are. C++ is a multi-paradigm language, deal with it. Its OOP, procedural, *and* generic. The STL is biased away from OOP, and towards generic programming. GUIs are inherently well-suited for OOP. Ergo, if you’re doing a GUI, you take advantage of C++’s multi-paradigm nature and use something other than the STL. In C++, you use what works. You don’t avoid a good solution to a problem just because it doesn’t fit some sort of ideology.
Now, its not ideal that a seperate preprocessor is necessary, but its true that it is necessary. When a version of C++ comes out that does signals/slots, properties, introspection, etc, without the burdensome template syntax and aggressive static-typing restrictions, then moc can be replaced. Until then, its all just a lot of hand-waving.
Try Microsoft’s Explorer’s multi-column-view and see how it should be (select b, navigate to e, press shift and click).
Gee, I never noticed that. I guess very few people use this method for selecting files.
What you can do, however, is select b, hold shift, then press the down arrow until you get to e.
Judging QT on such a minor bug seems a bit harsh. Meanwhile, my Win2K station at work has a bug with WMP’s video preview – it completely freezes explorer whenever I select a video file. That’s what I consider a real bug – the system shouldn’t prevent me from conducting other file business while waiting for the video component to respond!
“What you can do, however, is select b, hold shift, then press the down arrow until you get to e. ”
Of course you also never noticed that arrow key navigation in Konqs multi-colum-view is buggy (yes, it is).
Using SHIFT to select multiple items from a multi-colum-list is standard.
This is no minor bug, working keyboard support is an essential feature for every desktop environment.
The bug you mention seems to be an installation dependent bug.
The buggy keyboard support in widely used Qt classes is present for every KDE user.
Of course a lot of users are happy alone with colourful icons and good-looking themes and therefore don’t notice such bugs, but that doesn’t change things.
I still don’t get it. Using shift-click results in ‘b’ and ‘e’ getting selected, as expected. Qt creates a bounding box and highlights everything in that box, just like it does for click-drag. Doesn’t look like a bug to me, but a conscious design decision. If you don’t like the way it works, why not just file a bug report?
I also don’t see any of these arrow-key problems you mention. It works just fine here. More details?
I don’t know what you’re talking about. There are no bugs in Konq 3.2.1 concerning keyboard control. CTRL and SHIFT work like expected (like with the mouse).
I can select whatever I want in a Konq window and notice no counterintuitiveness there. Maybe you’re using KDE 1.0?
Of course you also never noticed that arrow key navigation in Konqs multi-colum-view is buggy (yes, it is).
Well, what I just described works, and it works exactly like in Windows Explorer. Select item, hold shift and press the down arrow until you reach the last item you want to select. I just tried it in Windows Explorer and it works exactly the same way.
In fact, I tried what you described:
Try Microsoft’s Explorer’s multi-column-view and see how it should be (select b, navigate to e, press shift and click).
And you know what? It works the same on Windows 2K and KDE. So really, I don’t see what the problem is here. In any case, there are so much more useful features that Konq has that Windows Explorer doesn’t that such a minor annoyance (so minor we’re all having trouble replicating it) is quite irrelevant.
Konq rules, Windows Explorer sucks. Flame on.
Don’t get the idea that KDE people believe that KDE is bug-free and perfect. Its far from that. There was a reason 3.2.1 was released so quickly after 3.2.0! But your comments about the IconView bugs are irrelevent to this discussion. Given that the people who actually use Konqueror still seem to be fuzzy on precisely what the problem is means that its not an earth-shattering deficiency in Qt, but rather, a run-of-the-mill bug. As such, the appropriate action is to submit a bug to bugs.kde.org. They are always receptive to detailed bug reports!
PS> To tell the truth, I don’t know if this thing in particular is a bug. I think its an intentional behavior that just happens to be different from Explorer’s. Qt’s keyboarding mechanism selects the same way its mouse mechanism selects, while Explorer treats the thing as one long list and selects everything inbetween.
Have you heard of libsigc++ before?
http://libsigc.sourceforge.net/ What advantages does QT signals and slots have over the libsigc++?
I have to use Qt 3.x for a project at work.
Well, it’s by far the worst GUI toolkit I’ve ever used. Sure it’s portable and offers a lot of features, but it’s always imposing itself in the projet instead of being integrated seamlessly.
The MOC is really a PITA, aside from being an additional step in compilation (and thus more error prone) it often produces source that cannot be compiled anymore; it’s integration with precompiled headers is pathetic. MOC only did one thing for me: waste my time.
Most of the tools given to help you are mostly useless if you’re project goes beyond the tutorial level. I had to do most things by hand to avoid everything else getting screwed.
Even if OOP tends to be the most adapted to GUI programming, Qt API is still bloated and outdated. I hoped Qt 4.0 would bring a fresh API, 100% standard C++ compliant and no MOC, but…
I don’t understand how you can say that std containers with pointers is bad, or that pointers are bad… because with Qt you’re always messing with pointers!!! It’s just that Qt has an obscure way of dealing with memory allocation, which is kinda error prone if you’re not carefull.
About signals and slots, as said above there is libsigc++ and Boost.Signals. Which proves again that MOC is just an outdated hack/workaround.
QT looks like a very nice toolkit, but unfortunately I can’t touch it. As far as I can tell, it would be illegal for me to write QT-based software using my favorite license, the BSD license.
Those who frequent these boards will know that I am *not* a fan of the GPL. However, what you are saying is completely ridiculous for several reasons. The (revised) BSD license is GPL compatible. You don’t need to make excemptions for linking BSD licensed code with GPL licensed code whatsoever.
This is further compounded by the fact that Qt/X11 is dual licensed under both the GPL and QPL. This means that you can even use GPL incompatible licenses like the Apache license with Qt/X11.
Now if only Trolltech would release a free Windows version. Oh well, such is life.
Qt Non-Commercial 2.3 for Windows is still available off ftp://ftp.trolltech.com/
Qt Non-Commercial 3.2 for Windows also comes bundled with “C++ GUI Programming With Qt 3”, a $30 book
QT looks like a very nice toolkit, but unfortunately I can’t touch it. As far as I can tell, it would be illegal for me to write QT-based software using my favorite license, the BSD license.
Those who frequent these boards will know that I am *not* a fan of the GPL. However, what you are saying is completely ridiculous for several reasons. The (revised) BSD license is GPL compatible. You don’t need to make excemptions for linking BSD licensed code with GPL licensed code whatsoever.
This is further compounded by the fact that Qt/X11 is dual licensed under both the GPL and QPL. This means that you can even use GPL incompatible licenses like the Apache license with Qt/X11.
Now if only Trolltech would release a free Windows version. Oh well, such is life.
Qt Non-Commercial 2.3 for Windows is still available off ftp://ftp.trolltech.com/
Qt Non-Commercial 3.2 for Windows also comes bundled with “C++ GUI Programming With Qt 3”, a $30 book
When a GUI toolkit connects to an SQL server, you know something’s wrong…
Out of curiosity, what area of CS do you work in?
I manage memory manually sometimes, but that’s because I need to make sure large portions of memory get cleared so I can keep the memory load reasonable. Particularly, in recursive structures I sometimes want to deallocate memory before recursing furthur. Smart pointers would not do this for me, the smart pointer would clear out the memory only after the recursion returns and the particular recursive call is poped off the stack (with the last pointer instance).
So sometimes you really do need to manage memory manually. Granted, I could get around this by scoping, but really that’s no better than just calling delete.
Yes, I’ve heard of libsigc++ and Boost.Signals too. I wouldn’t say that Qt’s solution was superior if I didn’t understand the competition. They are good solutions, but Qt’s signal/slot mechanism is more flexible and has a nicer syntax. The good thing about Qt’s system is that it does runtime checking of types rather than static checking of types. This makes it much easier to program, because types don’t have to match up exactly at compile time.
Read this paper: http://doc.trolltech.com/3.3/templates.html
> it’s integration with precompiled headers is pathetic.
> MOC only did one thing for me: waste my time
Since moc doesn’t generate any code for header files, I think it might not just be your time being wasted here.
Even if OOP tends to be the most adapted to GUI programming, Qt API is still bloated and outdated.
Pure blather. How is Qt’s API bloated and outdated? Specific examples, please! If the inclusion of XML and database components really bothers you, rest easy that Qt4 splits them into seperate libraries. Still I don’t see the big deal — Qt is already a very small library in terms of raw number of bytes.
100% standard C++ compliant
Who except ideological conformists care about “100% C++”? 100% C++ is 100% wrong for certain tasks. I don’t understand why so many commercial programmers have this intense desire to be told exactly what path to follow. C++ is good, so you have to do everything the 100% C++ way? That’s intellectual laziness, nothing more!
I don’t understand how you can say that std containers with pointers is bad
The STL standard containers are not optimally designed to be used with pointers. The fault isn’t with pointers, but with the standard containers! STL containers don’t support reference semantics. They treat pointers as first-class value objects. That means that you have to take care of the indirection manually. For every template structure where:
Container>foo> means a “container of foo,” there should be a container where the same construct means a “container of foo references.” Heck, it could even by a policy parameter. That way, you could actually take advantage of the STL’s memory management facilities.
or that pointers are bad…
Where did I say that pointers are bad? I wish C++ would ditch them entirely, and stick with references everywhere, but whatever. Reference semantics ar entirely warrented in some situations.
because with Qt you’re always messing with pointers!!!
Yes! Because GUIs are object-oriented and dynamic and that’s the only way to get those qualities in C++.
It’s just that Qt has an obscure way of dealing with memory allocation
Qt’s memory allocation strategy is very straightforward. Qt parent objects own their children. That means that parent widgets delete child widgets, containers delete their elements, etc. Tons of people use Qt, and I don’t hear many complaints about Qt’s memory management.
I’m not a CS, but an engineering major. I work, though, as a programmer on software-defined radios.
In your example of manual memory management, you can accomplish the same thing with smart pointers by clearing it before continuing to recurse. Boost’s shared_ptr template has a clear() function.
Cool, I didn’t know that they had such a function. I’ll have to take a closer look at boost smart pointers.
[OT This lack of threading is really annoying]
>>It’s just that Qt has an obscure way of dealing with memory allocation
>Qt’s memory allocation strategy is very straightforward. Qt parent objects own their children. That means that parent widgets delete child widgets, containers delete their elements, etc. Tons of people use Qt, and I don’t hear many complaints about Qt’s memory management.
Well you must admit that it is not very C++ like, I remember that one DrDobbs editor who was looking for a toolkit rejected Qt because of its memory handling..
So some people *are* bothered by Qt’s memory handling.
What is “not very C++-like?” For that matter, what is “C++-like?” You’re not actually making an argument for-or-against Qt’s way of handling memory. Rather, you’re just appealing to convention.
I agree with his points about “shift” and click to select.
If you come from Windows background then it seems a bug as you expect the multi-column view to be more of a long list that has wrapped on reaching the bottom of the window. So if you select the first file in column one, press shift and click on a file in the middle of the column two, you would have expected all of the first column and part of the second column to be selected.
I am also unsure if its a bug or feature, i know its driven me batty having then to do additional Ctrl and click to get the extra files
The change in how iterators can be handled is certainly welcome, I’ve always found that confusing because of my background in Java and lack of experience with C++.
I do hope that Trolltech once again makes a non-commercial version available freely downloadable for Windows though, I don’t want to have to buy “C++ GUI programming with Qt x” every time there is a new release, that book was around $70 CAD last time I checked. Besides I can’t statically compile apps with it so its not like I’m going to be able to distribute anything without buying a commercial version anyway.