Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Open Source KDE

Qt 5.0 Released 161

Posted by Unknown Lamer
from the half-of-common-lisp dept.
sfcrazy writes "The Qt project and Digia, the company behind Qt framework, have released the most awaited C++ framework for developers, Qt 5.0. The company claims it's one of the best releases to date and has invested a significant amount of time behind this release. It's an overhaul of the Qt 4.x series and makes Qt fit for the future." Update: 12/19 17:46 GMT by U L : Major new features include an overhauled graphics layer, full integration of Qt Quick for creating flexible interfaces using Javascript, and increased modularization including the first steps toward de-emphasizing QtWidgets by separating them into their own module.
This discussion has been archived. No new comments can be posted.

Qt 5.0 Released

Comments Filter:
  • C++ Standards (Score:4, Interesting)

    by joelholdsworth (1095165) on Wednesday December 19, 2012 @12:54PM (#42337969)
    Did they make any moves towards using standard C++ features rather than the MOC ugliness? What with Boost::Signals, sigcxx and C++11, I see no reason why they have to bastardise the language to provide signals.
    • RTFA: They have made some good progress on this - but I can't tell if MOC is dead yet.
      • by Desler (1608317)

        They aren't eliminating MOC. For one thing, they support a number of compilers that don't have and probably never will have full C++11 support.

        • by stenvar (2789879)

          You don't need C++11 to replace MOC. MOC was obsoleted by C++ features many years ago.

          • Re: (Score:2, Informative)

            by loufoque (1400831)

            Let me add that In this particular instance, many is 15 years.

            • by Urkki (668283)

              Let me add that In this particular instance, many is 15 years.

              How do you call a C++ method by it's name from QML or javascript or C++ plugin without some kind of pre-prosessing step which actually stores the method names and argument types somehow to make invocation possible?

              • by loufoque (1400831)

                dlsym(h, "my_method")
                There is no need to store it, it's already in the symbol table.

                If you do want to store it, there is no need to use an external preprocessor anyway.

                • dlsym(h, "my_method") There is no need to store it, it's already in the symbol table.

                  If you do want to store it, there is no need to use an external preprocessor anyway.

                  That works for functions, but not Class Methods that require an instance of the class. And, even more so, how do you do it in a multi-platform environment in a uniform way? (http://en.wikipedia.org/wiki/Dynamic_loading). Windows doesn't use dlopen/dlsym/dlclose but has its own Win32 functions to do something similar. You're also relying on RTTI; and not every compiler or environment supported by Qt supports RTTI. (RTTI also has its own run-time overhead which is bad in embedded environments like what Qt sup

                  • by loufoque (1400831)

                    It works for any symbol, regardless of its type.
                    This has nothing to do with RTTI.

                    The API for plug-ins is platform-specific since there is no standard interface for C++ plug-ins.

                    • Re:C++ Standards (Score:5, Informative)

                      by TemporalBeing (803363) <bm_witnessNO@SPAMyahoo.com> on Wednesday December 19, 2012 @04:44PM (#42341151) Homepage Journal

                      It works for any symbol, regardless of its type. This has nothing to do with RTTI.

                      The API for plug-ins is platform-specific since there is no standard interface for C++ plug-ins.

                      Yes, you could use dlsym() when building the table MOC builds for the connector calls. That's it. That's also a very very small part of what MOC does. That could be done as part of the object constructor...except now you need to store both static compile-time information (the functions you want to add) and dynamic run-time information instead of just the static compile time stuff that MOC generates (in the moc_*.cpp files).

                      RTTI does a good bit of the rest of what MOC does. In neither case are they both supported by all platform+compiler combinations that Qt supports.

                      Qt5 now allows C++11 lambas in signal/slots; but only if you enable C++11 functionality when you build it - they still support compilers that don't support C++11 lambas.

                    • It works for any symbol, regardless of its type.

                      You're still missing the point. How exactly, given a QObject*, can you ask it to give you some wrapper encapsulating a method named "foo"? Even if you're willing to do C++ name mangling yourself in a platform-specific way, you still need to know the actual type of the object to which you have the pointer, meaning that you need RTTI.

                    • The problem is that the moc implements something more like the Common Lisp Object System's metaobject protocol for C++; resolving symbols at runtime is a tiny portion of what it does. dlsym and analogues on other platforms are also horrendously unsafe; a one way ticket to strange segfault bugs when you cast the result to the wrong type. And since C/C++ types are not first class, you can't even construct the casts at runtime! (Ok, maybe C++11 has some new foo_cast template, I'll admit my C++ is a bit rusty).

                    • by loufoque (1400831)

                      I simply replied to the question "how do you call a C++ method by its name from a C++ plugin".
                      I don't see what this has to do with MOC.
                      There is no need to build any table either. There is no need to store anything, nor to use RTTI.

                      If you really wanted to generate tables of data (which again, I repeat, is not needed to do this), you still wouldn't need MOC anyway. You can just use macros and potentially templates to do that.

                    • by loufoque (1400831)

                      Calling a member function through a pointer to base bound to a derived object works fine assuming the function is virtual.

                    • by loufoque (1400831)

                      It does work in all cases.

                    • by loufoque (1400831)

                      If you want to do duck typing, which is probably a bad idea, you'll indeed need to generate some runtime reflection data.

                      I don't see how generating that data is awkward using standard mechanisms.

                    • It does work in all cases.

                      Only for functions, not for non-static class members; and (as I pointed out) not efficiently enough for how Qt manages signals/slots; not likely sufficiently enough for how Boost handles them either.

                    • by loufoque (1400831)

                      It works fine for any symbol, including non-static class members or whatever else you've put in your binary. dlsym does not care about the type of the symbol or the calling convention to call it, that's up to you to handle.
                      Now then, what you can argue is that this isn't a nice programming interface. It isn't, it's just how the platform does dynamic linking.

                    • Now then, what you can argue is that this isn't a nice programming interface. It isn't, it's just how the platform does dynamic linking.

                      It's also not portable. dlopen()/etc are not on Windows - which has its own unique interface for doing the same thing.

                • by Urkki (668283)

                  dlsym(h, "my_method")
                  There is no need to store it, it's already in the symbol table.

                  If you do want to store it, there is no need to use an external preprocessor anyway.

                  Sorry, wrong answer. C++ method name symbols are mangled to include class name and parameters. Worse, this mangling is not standardized, it is compiler specific. In other words, that is not a method name, that is a C function name in the example you gave.

                  But it's even worse than just generating the symbol name. With virtual methods, you have to determine at runtime, what is the real class of the object pointer, because you need to call differently named method based on that. So, could be done with RTTI and

                  • by loufoque (1400831)

                    It's a symbol name. Finding the symbol name of a particular member function is not a problem. You don't need the type either, the base type is enough.

    • Re:C++ Standards (Score:5, Informative)

      by N3Roaster (888781) <nealw @ a c m .org> on Wednesday December 19, 2012 @01:04PM (#42338081) Homepage Journal

      Yes and no. The signals and slots mechanism is still there and it's still using moc, but there's a new connection syntax available that's a lot more C++ like, allows C++11 lambdas in place of slots, and offers compile-time checking of connections that previously would just fail at run time. Won't please the purists, but it's a step in the right direction.

    • by Noughmad (1044096)

      Yes, they did. See the wiki page [qt-project.org].

    • Signals and slots (Score:5, Informative)

      by zenyu (248067) on Wednesday December 19, 2012 @01:37PM (#42338391)

      You can now use any C++ function as the target of a signal using the new QObject::connect() syntax. This is a huge win because with the new syntax the compiler and linker can check that the connections are valid instead missed connections just causing a run-time error.

      The moc preprocessor is still required for QObject derived classes, mostly for the translation framework and also to provide support for the old signal/slot syntax which is still allowed. Qt5 doesn't require a C++11 compliant compiler, which is a good thing since there aren't yet any fully compliant compilers. I'm sure if there is a Qt6 it will require C++11 and use those features.

      Some of the really cool C++11 features like move constructors aren't necessary with Qt because it's containers implement reference counted copy-on-write, so when you assign a QMap from another QMap no copy is made, and if the old QMap was an rvalue then there is never a need for the copy to be made when the new QMap is modified. One of the big improvements Qt4 made over Qt3 was to make container assignment atomic so this mechanism worked with threaded code and defensive deep copies weren't necessary anymore.

      • Qt5 doesn't require a C++11 compliant compiler, which is a good thing since there aren't yet any fully compliant compilers. I'm sure if there is a Qt6 it will require C++11 and use those features.

        C++11 is not necessary for MOC-less signals/slots - Boost has been offering them for years with all existing compilers.

        Some of the really cool C++11 features like move constructors aren't necessary with Qt because it's containers implement reference counted copy-on-write, so when you assign a QMap from another QMap no copy is made

        Sure, but what about your own types? Implementing COW is much harder than implementing a move constructor. I do hope that Qt containers use move semantics for elements when available, at least?

        Also, COW is not free when it's thread-safe. Those atomic increments and decrements do add up, especially on instances of types that are copied around a lot (strings are a classic example of that).

        • by Urkki (668283)

          Sure, but what about your own types? Implementing COW is much harder than implementing a move constructor.

          In case you are genuinely interested, it's not hard, because there's a helper class for that: QSharedDataPointer [qt-project.org]

          • That helps. On the other hand, if you use that trick (copying pointer to actual data around), you get the overhead of an extra indirection on every field access, as well as a heap allocation for every instantiated obejct (even if it's instantiated on stack). As I understand, Qt pretty much has to do it anyway for its classes to enable binary compatibility between minor releases via the usual Pimpl idiom, but it's not necessarily desirable for user classes.

    • Re:C++ Standards (Score:4, Informative)

      by scorp1us (235526) on Wednesday December 19, 2012 @11:56PM (#42344851) Journal

      First, it's not bastardized. C++11 is the bastardization, because it results in code fragmentation. That wonderful cross platform C++11 function you write can only be targeted by C++11 compilers. Meanwhile in Qt land everything keeps working on your legacy compiler. The fact that it uses compiler macros to accomplish cross-platform cross-compiler interoperability does not lend itself to "bastardization"

      MOC is not ugly, though I would prefer a C# approach of not having to separate it into a H file, but this is more a C++ thing than a Qt thing. I love the QMeta* that allows me to have introsepction at run time (again x-platform) and I can even dynamically create classes. Can C++11 do that? (Well i guess it can if it's using Qt) But they are adding C++11 syntax if you are using a C++11 compiler and want to limit your portability.

  • How is this going to impact KDE? Will this be the start of KDE5?
    • by NotBorg (829820)
      I read somewhere a while back that KDE was going to try to reduce the duplication of effort between KDE and Qt and rely more on Qt. I don't know where they're at with this but I'd like to here more.
  • A glorious day (Score:5, Insightful)

    by mozumder (178398) on Wednesday December 19, 2012 @12:56PM (#42337993)

    This really is the best cross-platform Apps framework out there. Far better than HTML5/Javascript.

  • So, is it fully standard C++ now or do you still have to use their hokey preprocessor?

    • Re: (Score:2, Informative)

      by loufoque (1400831)

      It's still a moc'ery of C++, if that's what you're asking.
      And it still duplicates everything that's in the standard library, including containers, threads, files, etc.

      • by Anonymous Coward

        Fixed this for you:

        And it still duplicates everything that's NOW in the standard library, including containers, threads, files, etc. for the set of compilers and run times that are compliant.

        • by vurian (645456)
          Well, you might even amend it to "provides much better implementations of things that are in the STL, , including containers, threads, files, lists etc."
    • by Urkki (668283)

      So, is it fully standard C++ now or do you still have to use their hokey preprocessor?

      Well, for many things Qt requires reflection features not provided with C++. When/if C++ starts to provide them as part of the language, I'm sure moc will become thing of the past, and be replaced with just translation data extractor, which you can leave out if you do not care about internationalization. But for what it's worth, with the new signal-slot connect syntax it's probably possible to have meaningful programs without running moc, if that makes someone happy.

    • by suy (1908306)

      So, is it fully standard C++ now or do you still have to use their hokey preprocessor?

      Qt is, and always has been fully standard C++. The "moc" program is not a preprocessor, is just a tool, more precisely, just a code generator that writes for you some files that you have to either include at the end of your ".cpp" or you have to compile and link like other hand-coded files. If you use QMake, or CMake or any other buildsystem that has some Qt support (and most do), is completely effortless.

      At a first glance, you see things that might look like an extension to the language, because you see st

      • How exactly the magic Qt keywords like "slots" is implemented is really an implementation detail. From programmer's perspective, they are language extensions, because they introduce some new and important semantics into the language. The fact that they're handled by a separate codegen tool and stripped out of the code that's fed to the C++ compiler is irrelevant - you could just as well implement them directly in the compiler without changing their meaning, and it wouldn't magically change what they are.

        Any

  • How is Qt Quick? (Score:4, Interesting)

    by dannydawg5 (910769) on Wednesday December 19, 2012 @02:24PM (#42338909)

    I used Qt Quick briefly. It seems like you get a lot of deep powerful customization, but that comes at a cost. It eventually pissed me off so I went back to QWidget, and my productivity soared.

    I would not have completed my project in a reasonable time using Qt Quick. It is not "quick". Sometimes, you just want to drop tables, check boxes, buttons, etc. on to your main window, tie the click event to a slot, and call it done. You are fine with whatever default styling and rendering that Qt and the OS decide is appropriate for the widget's click/hover/etc event.

    It seems with Qt Quick, you have to specify all that nonsense. Plus, the Qt Quick editor tool felt complex and confusing. I avoided it and did everything by hand. Qt Designer for QWidgets is a drag-n-drop breeze. I even got my manager on board after he saw me using it. He is an EE, and he really likes it. He is used to spending $500 on Visual Studio Pro to what Qt Designer does better for free.

    Maybe I just needed to study Qt Quick more to get past the learning curve, but I knew how to do it the widget way, and I wanted the project done.

    Has anybody had success migrating their project from QWidgets to Qt Quick? Unless I see a strong compelling reason, I am sticking with QWidgets. It works really well for me.

    • My understanding is that the big problem with Qt Quick is the lack of all the usual widgets. There really isn't any particular reason why you shouldn't be able to define QML graphs in terms of "I want this button here and this textbox there", and them assuming the default theme etc.

    • If you are use to using QWidget and that is what you are comfortable with, then there is absolutely zero need for you to try and pick up Qt Quick. Qt Quick is really good at building one offs that you need for small tasks, think million little widgets here, not database editor. Qt5 is still centered very much around C++ and the people who wrote Qt are very aware that Qt Quick "is not for everyone".

      You may find yourself pulling up Qt Quick for implementing a "find dialog" or a "insert criteria dialog",
    • by Urkki (668283)

      Has anybody had success migrating their project from QWidgets to Qt Quick? Unless I see a strong compelling reason, I am sticking with QWidgets. It works really well for me.

      For an existing project, I think the only compelling reason would be, if you want a bling-bling GUI for touch interaction. Think of flick scrolling, multi-finger zoom&pan, animated transitions. And then it would need to be a complete UI redesign.

      But, in 1-2 years, I think almost all new displays even on desktop, and certainly on laptops, will be touch screens. I think this is a good time to start thinking about a full UI re-design for any application, where displaying information is important.

      • by vurian (645456)
        Often it's possible to do both. For Krita, which has been around as a QWidget application for more than ten years now, it was possible to make a Qt Quick-based version in about four months with two people: Krita Sketch, which offers almost all the functionality of Krita Desktop, but touch-enable.

6 Curses = 1 Hexahex

Working...