Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
GUI Graphics Programming

Qt 5.5 Released 80

New submitter mx+b writes: The latest version of Qt, the cross platform GUI toolkit and development platform, is out for all major platforms. Highlights include better 3D, multimedia, and web support, as well as better support for the latest OS X and Windows releases (including Windows 10) and more Linux distributions.
This discussion has been archived. No new comments can be posted.

Qt 5.5 Released

Comments Filter:
  • When I've read "web support" I though "Cool! I will finally get good support to run QT apps on a standard browser". But alas, it just means running a Chromium engine embedded in a QT app. Who wants to run web sites in an app nowadays instead of opening them directly in a browser?

    • by UPi ( 137083 )

      Using web technologies to embed rich content into your application is not unheard of. The Steam client comes to mind as an obvious example: most of their UI lives in a webkit container. We do it at the company I work for, because it allows us to release new client and server versions separately. (We have a good reason to do that, not going into details.)

      The alternative is either to launch an external browser and display your application's content there, which is cumbersome and then you end up having to test

    • Web support in apps is for cows, you are all cows, moo?

    • Re: (Score:3, Informative)

      by Gravis Zero ( 934156 )

      When I've read "web support" I though "Cool! I will finally get good support to run QT apps on a standard browser".

      actually, you can do that []

      But alas, it just means running a Chromium engine embedded in a QT app.

      no, it uses WebKit [] while Chromium uses Blink [], a fork of WebKit.

      Who wants to run web sites in an app nowadays instead of opening them directly in a browser?

      well... if you wrote a web browser in qt [] you would. what about an RSS feed reader []? it has it's uses but it's true it shouldn't be abused.

      • Re:Web support (Score:4, Informative)

        by Carewolf ( 581105 ) on Thursday July 02, 2015 @06:25AM (#50031475) Homepage

        no, it uses WebKit [] while Chromium uses Blink [], a fork of WebKit.

        No, the new web module for Qt called QtWebEngine is based on Chromium, and yes, it is pretty much running a Chromium webview inside your application. It is the cost of having to have a standard web engine that works on all platforms, after Apple became too difficult to work with after Google left.

    • I found Wt [] really interesting, replacing desktop UI controls with their equivalent in HTML ones, passing the data back to the same c++ backend that the desktop would use. I'm sure it'd be a cool thing to replace your QApplication woth WApplication and have it turn into a html5 GUI, but what's the chance the GUI components supported would just be the most basic?

  • One of these days I'll have to get "into" QT. It looks like a great successor to some of the concepts originating with Neuron Data's tools, which I spent a lot of years learning and working with. For now I've been focused on Java server code, but I've never really been a fan of Java for writing client applications, and I've no interest in buying an Android device just so I can stick with Java while working on front-end code.

    No, to me, client side means an actual computer, not a mobile device. And QT h

    • Java is excellent for client code, first of all we have Swing and if you like to use Groovy: Griffon, a GUI framework, and secondly you have JavaFX the new Java GUI Framework.

      Against Java and for Qt only speak, what you don't want anyway: portability to mobile devices.

  • by Prien715 ( 251944 ) <> on Thursday July 02, 2015 @03:19AM (#50031029) Journal

    Qt is not just a GUI toolkit. Doxygen has been using it for years. I do high performance computing and copy-on-write data structures (as Scott Myer suggest a decade ago in "More Effective C++") means I don't have to worry about functions returning references to a std::vector because QVector's copy constructor is O(1) as Scott Myers recommended a decade ago. I have a sane cross-platform cross-DB SQL interface. My strings are Unicode (and copy-on-write).
    Qt allows you to write high performance code but in a style closer to Perl (especially with 11. "Auto" is "my") while enabling a coder to use high performance C code without needing to write fancy interfaces and compile schemes Everything from threading (QtConcurrent is great!) to file access to JSON to regex to is well-documented and the compile errors are sane (see: boost) and the code is terse (also: boost).
    If you're doing serious C++ development with a small team, Qt is the best way to get things done in my experience...and it's also trivial to make a GUI to represent a SQL query.

    • Mod parent up! The value of Qt as at a cross-platform c++ platform / enhancement is much undervalued. It is so much more than just part of a Desktop Environiment and the GUI Toolkit reallky is just a small part.
    • by jma05 ( 897351 )

      I don't disagree with anything, but I am just curious: what kind of improvements did you get with C++/Qt stack over say, Java or Scala? (I am assuming you evaluated alternatives) Say, over 2x improvement in performance? Much lower memory utilization?

      • by taupter ( 139818 )

        1. Native appearance is supported since a long ago in Qt, making a Qt program display in an appeasing way no matter what OS it is run on.
        2. No VM.
        3. No garbage collector.
        4. Compiled code. Native speeds. Performance dependent on compiler. Can use MinGW, GCC, MSVC2010-2013, LLVM/Clang. No JNI.
        5. Legacy code. Way easier to port already written code instead of translating it to another language and having to learn everything again and possibly adding new bugs and surely losing time redoing what is already done.

        • by jma05 ( 897351 )

          I understand all that. I used Qt myself, but just for simple GUIs. I was just wondering what his real world numbers were. I was not challenging him for his choice. I know the micro-benchmarks between native and VM code. I was curious of how things fared in his larger apps. I normally do JVM for long-running server code, but C++11 and onwards is increasingly attractive, although JVM is still a bit simpler to work with, on the whole. I am exclusively interested in his (or anyone else's) real world experiences

        • Another very important point is deployment. Deploy a Qt application to say, Windows, you ship the needed Qt libs as dll's with your program (installed in the program folder). User installs, and starts the program like a native one.

          Java: Ship a jar (or say exe), and then the user has to first download a JRE. Start your program, and the user has to wait with a startup screen, cause the JRE takes time to load. Horrible end user experience
          • by jma05 ( 897351 )

            You can bundle JRE with your jar/exe, if you don't want the user to separately download a runtime. Many Eclipse Rich Client Apps do this. I have done it myself. As someone who used Delphi/C++ Builder and is very used to static linking to a 1-2 MB distributables with no further dependencies, I am not that happy with Qt dll sizes for client apps. Its certainly better than Java, but is quite bloated for native code. All other native solutions are much more compact (Qt of course wins by feature set). Static lin

      • I don't have a direct comparison with my current project, but having worked on other projects in the HPC, it's not 2x. It's more like (O)n vs (O) n log n -- or worse. There was a project I worked on with did feature tracking and at one point, I was asked to save the data for a small project to a DB so another product within our company (team of around 20 on each project) who was working on equivalent functionality in Java. I lazily saved the whole thing for each change which took under a second, but it t

        • by jma05 ( 897351 )

          Thanks. That's useful feedback. Obviously, this topic is complicated with several factors to muddy the waters.

          > 90% of your time is usually spent in 5% of your code, so it's really the ability to optimize easily when you need to without resorting to convoluted tricks and hooks into other languages.

          Interestingly, the Python/glue-language philosophy is just the opposite, for exactly the same reasons. Since it is just the 5% of the code that needs optimization, it says: why not write that in C/C++ and the r

          • why not write that in C/C++ and the rest in something easier?

            I guess that's my point -- it's not easier anymore.

            Python comes with its own problems; it's hard to write object oriented code in a weakly typed language because (1) changing object interfaces means your code appears to work until it suddenly fails during execution (typed languages check at compile time) (2) no IDE can autocomplete methods on an object (because it's impossible to infer the type and thus the impossible to infer the methods able to

  • How well does using Qt for iOS and Android development work? Last I checked, the documentation on how to effectively utilize Qt for this purpose wasn't nearly as informative as using it for it's more traditional use case. I would love to be able to do cross platform mobile development using C++.
    • by taupter ( 139818 )

      Actually it's pretty straightforward. Compile and run. It will deploy to an AVD, an Android device, to virtual and physical iOS devices, all directly from the Qt Creator IDE.

  • by Anonymous Coward

    QT Mobile was a total farce and joke.

    We dumped it after attempting to do a project on it. TOTAL FAILURE.

    NEVER AGAIN will we believe cross platform claims. Total hype, lack of features, total fail.

    • I'm sure lots of people would be interested in the details of your experience with Qt Mobile.

Loose bits sink chips.