PDA

View Full Version : Elegant Qt's future?



magland
12th June 2007, 16:15
Qt is by far the most elegant, useful, and logical toolkit that I have ever come across. As Qt incorporates more advanced features, I wonder if it is in danger of losing its basic simplicity. Can we trust Trolltech developers to continue making good design decisions for the forseeable future?

In other words, with future releases will Qt become even simpler, more robust, and more elegant, or will it become increasingly convoluted and perhaps less flexible. And which of these trends does Qt's history support? What political/legal/economic factors are involved?

I'm interested in QtCentre member perspectives.

Michiel
12th June 2007, 16:49
I mostly agree with you. And Qt seems to have become more simple and elegant in the transition from Qt3 to Qt4. I don't see why that should change in the future.

However, Qt has several limitations. Most of them because of the limitations of C++:
* Qt provides several missing features (class properties, signals/slots). But because of C++, the syntax and imlementation are clumsy. Did you know that signals and slots are about 10 times slower than they could be? They use c-strings instead of templates, because the C++ template system is too limited.
* The C++ standard library is too limited. This means that Qt had to create their own classes for strings, containers, etc. Although they are well made, they are incompatible with other libraries you might want to use.

wysota
12th June 2007, 17:35
Did you know that signals and slots are about 10 times slower than they could be? They use c-strings instead of templates, because the C++ template system is too limited.
That's a design decision and not limitation of templates. There are signal/slot implementations that use templates and they are indeed faster than Qt implementation, but the freedom to manipulate strings is a greater advantage than that small disadvantage regarding speed. You have to remember C++ is compiled, not interpreted, thus templates have to be instantiated during compilation, which means you have to know all names and signatures during compilation. So the string approach used by Qt is probably the most flexible there could be. Qt uses that approach extensively in several places to provide auto discovery and introspection of external components. But I wouldn't agree Qt signal/slots are 10 times slower than they could be. A signal emission and slot trigger unfolds into about 10 function calls and template implementation unfolds into 4-5 function calls, so the difference is not that big, especially compared to the fact that slots themselves are usually much more computation intensive.



The C++ standard library is too limited. This means that Qt had to create their own classes for strings, containers, etc.
This is not true. Qt implementation is in most cases indeed faster and better, but it's fully compatible with the standard library. Qt has its own implementation of containers mostly because it is deployed on platforms that don't have their own STL implementations.
Strings is a completely another thing - std::string and QString differ in every possible way.

Here are some nice things to read:
http://doc.trolltech.com/qq/qq13-styles.html
http://doc.trolltech.com/qq/qq13-apis.html
http://doc.trolltech.com/qq/qq16-dynamicqobject.html
http://doc.trolltech.com/qq/qq19-containers.html
http://doc.trolltech.com/qq/qq15-academic.html
http://doc.trolltech.com/qq/qq02-data-sharing-with-class.html

magland
12th June 2007, 19:41
Thanks for the interesting posts.... that's an important issue about whether the Qt implementation of signals and slots is efficient. I'd say it's certainly good for the programmer! - and as processor speeds continue to increase, I would expect signal/slot efficiency to become even less signficant as compared to other tasks.

Back to the original topic of this thread: will Qt continue to get better and not just bigger? I was impressed to see a step back w.r.t. designer moving from Qt3 to Qt4 (although I must admit, I was never a Qt3 programmer). Will this trend toward simplicity [not sure if this is the right word] continue, as I hope it does, and what factors are involved?

jacek
12th June 2007, 20:59
I was impressed to see a step back w.r.t. designer moving from Qt3 to Qt4 (although I must admit, I was never a Qt3 programmer).
On the contrary, the way that .ui files are handled in Qt4 is far more flexible than it was in Qt3, where you were forced to derive your class from QWidget, QDialog or QMainWindow. Now you can derive your forms from your own classes and still use .ui files.

The Trolls have dropped the possibility to use .ui.h files and removed the code editor from Qt Designer, but that was really a dead end --- I can't imagine using them for some serious work.


Will this trend toward simplicity [not sure if this is the right word] continue, as I hope it does, and what factors are involved?
I'm not sure if Qt can be simplier, although the Interview framework is a bit too complex for beginners and they tend to use QxxxWidgets instead of QxxxView, which in the end is just a waste of time. But that's not a matter of changing the API, but rather a documentation issue.

Certainly Qt will be more powerful in the future, just look at TT labs site and see what they're working on. They're not focusing on simply adding new modules to Qt, but rather adding more power to existing mechanisms.

wysota
12th June 2007, 21:42
Back to the original topic of this thread: will Qt continue to get better and not just bigger?
Please note that Qt is composed of few distinct libraries, so it's not bloating your code too much and the possibility to turn on and off some features gives some more flexibility to programmers.


I was impressed to see a step back w.r.t. designer moving from Qt3 to Qt4
I agree with Jacek - it was a great leap forward. For beginners switching from Qt3 it is difficult to understand why it's not possible to write code in Designer, but when you're used to some IDE learning a dummy pseudo-IDE (which Designer was at the time of Qt3) was just pain and a waste of time.

Currently I'm a little worried about the fact that code related features are coming back to Designer - especially the possibility to write ECMA scripts. If this continues, we might encounter another dead end.


Will this trend toward simplicity [not sure if this is the right word] continue, as I hope it does, and what factors are involved?
I think there is still much space for improvements, especially in Designer (like providing easy ways to extend it with new possibilities) and in Qt source code - especially getting rid of some hacks which are present there and using somewhat cleaner code that provides more flexibility when it comes to subclassing existing Qt classes.

But Trolls shouldn't focus on improving the existing code. We need things like cross platform multimedia support and more desktop integration. We have to assume that the technology will keep changing causing Qt to change as well - currently it's using top-notch features and solutions but they will once become outdated and be replaced with other techniques. Qt should be standing in the front line then.


But that's not a matter of changing the API, but rather a documentation issue.
I'd add that the community needs more experienced programmers that can teach others and more example code. The wiki we have, Trolltech Labs, Qtnode, blogs of some Qt related people - they should all help provide sample code and articles people can learn from.


They're not focusing on simply adding new modules to Qt, but rather adding more power to existing mechanisms.
Exactly. They are opening new possibilities using facilities Qt already has. Parallel computing, widgets on canvas or even QtTestLib.