Results 1 to 6 of 6

Thread: Elegant Qt's future?

  1. #1
    Join Date
    Feb 2007
    Location
    Philadelphia, USA
    Posts
    255
    Thanks
    43
    Thanked 21 Times in 21 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11

    Default Elegant Qt's future?

    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.

  2. #2
    Join Date
    Mar 2006
    Location
    The Netherlands
    Posts
    300
    Thanks
    9
    Thanked 29 Times in 29 Posts
    Qt products
    Qt3 Qt4
    Platforms
    Unix/X11

    Default Re: Elegant Qt's future?

    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.
    "The strength of a civilization is not measured by its ability to wage wars, but rather by its ability to prevent them." - Gene Roddenberry

  3. The following user says thank you to Michiel for this useful post:

    magland (12th June 2007)

  4. #3
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,364
    Thanks
    3
    Thanked 5,014 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: Elegant Qt's future?

    Quote Originally Posted by Michiel View Post
    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-dat...ith-class.html

  5. #4
    Join Date
    Feb 2007
    Location
    Philadelphia, USA
    Posts
    255
    Thanks
    43
    Thanked 21 Times in 21 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11

    Default Re: Elegant Qt's future?

    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?

  6. #5
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    5,372
    Thanks
    28
    Thanked 976 Times in 912 Posts
    Qt products
    Qt3 Qt4
    Platforms
    Unix/X11 Windows

    Default Re: Elegant Qt's future?

    Quote Originally Posted by magland View Post
    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.

    Quote Originally Posted by magland View Post
    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.

  7. The following user says thank you to jacek for this useful post:

    magland (12th June 2007)

  8. #6
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,364
    Thanks
    3
    Thanked 5,014 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: Elegant Qt's future?

    Quote Originally Posted by magland View Post
    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.

    Quote Originally Posted by jacek View Post
    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.

Similar Threads

  1. Invite QDateTime to go 8 secs on future uint
    By patrik08 in forum Newbie
    Replies: 4
    Last Post: 6th June 2006, 23:26

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Digia, Qt and their respective logos are trademarks of Digia Plc in Finland and/or other countries worldwide.