Lars Knoll

Evolution of the QML engine, part 1

QML as a technology has become increasingly important for the success of Qt. It allows for the creation of smooth, animated user interfaces, in line with expectations on the market today. There are three main features, that make it so suitable for UI creation. The first one is the declarative syntax, that makes it extremely easy to create these user interfaces and have both developers and UI designers work on the same code base. Secondly, the technology makes the integration of native code relatively easy, allowing to do much of the application logic and heavy lifting in C++. And finally, the choice of Javascript as an integral part of the QML language allows for easy prototyping and opens the technology up to a wider audience.

The engine as it is today is a fantastic basis and fills most of our users needs. However, it also has a couple of shortcomings and problems that will need to get solved in the future. This series of blogs is going to outline our findings and present the solutions that we are planning to implement for them. The goal will be to get to a better, more flexible and easier to maintain QML engine in the future.

So let’s start of with some of the problems we’re facing with the current engine.

  • Several object models
    The current QML engine uses the V8 Javascript engine to execute property bindings. Each QML item has several representations internally. One towards V8 (using the public V8 API), one towards the QML engine, and one to expose it as a QObject to native Qt. The problem here is that this requires the QML engine to keep these different representations in sync, leading to a lot of glue code and rather high memory consumption to hold the different representations.

  • Bindings done through JS closures
    Each binding is represented as a JS function closure towards V8. This requires rewriting the expression as a closure, and then letting V8 parse the rewritten expression once again. Evaluating the binding requires calling a JS function in V8 with quite a bit of overhead to instantiate the proper context for executing the binding. This is rather slow and lead to the development of a small expression interpreter (called V4) inside the QML engine that would evaluate simple expressions. This interpreter is many times faster than evaluating through V8.

  • Data type conversions
    One reason why evaluation of expressions in V8 is slow is the overhead of converting data types from Qt to V8 and vice versa. Accessing a Qt property would for example create a QVariant, that would then need to be converted to a V8::Value. If the variant was a string this involved copying the string data. To soften this, various caching mechanisms were introduced, but those came at the cost of increased memory usage and additional complexity in the code.

  • QML scoping rules
    QML is syntactically a tree of items. Inner items implicitly see properties of outer items leading to a well defined scope chain. Unfortunately this scope chain works differently than traditional Javascript and couldn’t be directly implemented with existing Javascript engines. The only way to do it directly would have been through nesting slow and deprecated with() statements. The current solution involves a very intrusive patch to V8 and still requires all QML properties to be looked up by name.

  • Throwing away QML type info
    QML as a language has type information. Javascript however is completely untyped. This lead to the fact that all type information got thrown away at QML compile time. Retaining the type information would allow us to optimise QML expressions a lot better.

  • iOS and WinRT support
    iOS does not allow making memory both executable and writable, something that existing JS engines require. WinRT doesn’t allow making memory executable at all. This makes it impossible to use V8 on these platforms without writing a full interpreter backend to V8.

  • Working with upstream V8
    As said above, we are currently forced to maintain a rather large and intrusive patch set on top of V8. There is no chance of merging these patches upstream, as V8 fully focuses on the browser use cases.

These different arguments have lead to a research project that was started Roberto Raggi and Aaron Kennedy in Nokia around a year ago, where they explored the feasibility of having a JS engine that is tailored to the use cases QML requires. The project with the codename v4vm was then transferred to Digia, where Simon, Erik and myself took it up and continued with it. It lived as a playground project on qt-project.org for the last couple of months.

Today we integrated this research project into a development branch of Qt Declarative, and we will continue to work on it there from now on.

The new engine contains a fully compliant ECMAScript 5.1 implementation, that runs on all platforms Qt supports. It contains a JIT that currently works on Linux, Mac and iOS. Integration into the current QML engine is currently done through a V8 compatible API layer which we plan to remove in the coming weeks. The engine can run all Qt Quick demos (with some minor glitches).

One of the things to note is that the engine is focused at QML use cases. This implies that we expect QML performance to become a lot better then it is today. Pure JS performance will on the other hand not be quite as good as what you get with V8 as a backend.

Still our current benchmark numbers are very promising also for pure JS code. The V8 benchmark runs currently around three times slower than the JS engine used in Qt 4.8 and Qt Quick 1, and we see a lot of potential for further optimisations.

Details about the new engine and our future plans will come in a followup post. You can find the code in the wip/v4 branch in the qtdeclarative repository. Feel free to play around with it. If you want to join development, feel free to contact us on #qt-v4vm on freenode.

Qt 5.1 Alpha Available

Two weeks ago we initiated the Qt 5.1 cycle by merging our development code base into the stable branch. Since then, the release team has been working on stabilizing the branch and we now have the first set of Qt 5.1 packages available. They are available from the new download.qt-project.org area for the open source version and in your customer portal for commercial users). The packages are source only and mainly for people already used to developing with Qt. Unless you feel comfortable compiling Qt on your own, you might want to wait for the beta which will come out within the next few weeks.

A lot has happened since the Qt 5.0 release in December, and I am truly impressed by the amount of new things that we managed to get done for this alpha release. Let’s have a short look at the most important new features.

Android & iOS

To start with, we have added preliminary support for Android and iOS to Qt 5.1. This release is fully usable on both platforms and you can begin to develop for both OSs immediately. All of qtbase (Qt Core, Gui, Network etc.) is implemented. Qt Quick works very nicely on Android and most sensors are supported. There are, however, certain limitations. Some parts of Multimedia are not fully implemented and Qt Quick is not yet working on iOS. Tooling is also still a work in progress, and not everything can be done from within Qt Creator yet, but many things are already  working nicely and smoothly.  As announced last year, full Android and iOS support will come with Qt 5.2, but Qt 5.1 provides a solid base for developers to create full applications for these two platforms.

Introduction of Qt Quick Controls

Then, we finally have cross-platform controls for Qt Quick. The modules ((QtQuick Controls (formerly known as Desktop Components)and Qt Quick Layouts) offer ready- available controls and layouts you can use to build your user interface, starting from buttons, layouts, over menu and toolbars to dialogs and high-level navigational controls. Of course, they have the look and feel of native widgets of the underlying platforms. They are currently implemented for the desktop operating systems, support for touch-based platforms will get added for Qt 5.2.

Add-ons

A couple of new modules got added as well. First of all, we brought back Qt Sensors as an add-on. The module is currently supported on Android, iOS, BlackBerry and Mer (Sailfish). A module for controlling serial ports (Qt SerialPort) has also been added, and we have an X11 specific add-on (Qt X11Extras).

Finally, we have added many other smaller features to the existing modules. For more details, please have a look at the Qt 5.1 feature list.

From now, we will start work on Qt 5.1 beta, which I  expect to be released a few weeks from now. Following that, Qt 5.1 final can be expected to come before the beginning of summer. Let us know what you think of our Qt 5.1 alpha. Enjoy!

 

 

Introducing Qt 5.0

Christmas is getting close, and it’s about time to unwrap one of the presents. You can get it at qt-project.org/downloads and learn more about about it via Qt 5.0 page on qt-project.org. For those of you that are commercial customers, simply visit your download area. If you are interested in evaluating the commercial version, please visit qt.digia.com/qt5.

So yes, it has finally happened:

The Qt Project and Digia have released Qt 5.0.

Let’s unwrap it a bit, and have a look at what’s inside.


This is Qt

 

Features

Qt 5.0 is a major overhaul over the Qt 4.x series that have been around since 2005. We have invested lots of time and effort to make Qt fit for the future.

Qt 5.0 comes as a full SDK package with binaries for Linux (64 and 32 bit), Mac OS X (10.7 and 10.8) and Windows. This implies that in addition to the Qt 5 frameworks, the packages come with Qt Creator 2.6, examples and full documentation.

The video below should give a good first impression of many of the new features in Qt 5.0, as well as its capabilities:


The following is a tour of what is new in Qt 5. It is an application written with Qt Quick, based on the modules shipped with Qt 5 and using a QML Presentation System.

The whole video is actually a screen capture of a Qt 5 based application using Qt Quick, OpenGL and WebKit.

For those of you who want to see it in real, running smoothly on your desktop or device, get Qt 5, then download the demo from qt.gitorious.org/qt-labs/qt5-launch-demo, open the project in Qt Creator, build it and enjoy!

The blog posts about the alpha, betas (beta1 and beta2) and release candidates (RC1 and RC2) contain a lot of additional details on the features that got added with Qt 5, and if you’re hungry for more details I can recommend reading up on these posts again. The roadmap presentation I gave at the Qt Developer Days this year also contains some more details.

Compatibility

But we haven’t forgotten where we’re coming from. Qt 5 is the successor to Qt 4, and we have done our utmost to keep Qt 5 as compatible with Qt 4.x as possible.

While we have cleaned up many things in our internal architecture and made Qt more modular, leaner and faster, we have managed to keep application compatibility in a way that most applications will work with very few changes and a simple recompile on Qt 5.

Of course, this also implies that Qt Widgets are fully supported and an essential part of Qt 5.

Qt Creator, being the biggest application we develop inside the Qt Project, is a prime example that shows this. A couple of weeks ago, we released Qt Creator 2.6 for use with Qt 4.8. The Qt 5 packages ship with Qt Creator 2.6.1 (which apart from bug fixes contains the same code base), but compiled against Qt 5.

Known issues, reporting bugs and contributing

As with every release, also this one has a few issues left that we know about. If you encounter a problem, please check the known issues page first, where you can find solutions and workarounds for common problems.

If you find any other bug in Qt 5, please help us to improve the product in future releases by reporting it to bugreports.qt-project.org. Ideas for or contributions of new features are also welcome. Simply check out qt-project.org/contribute for details.

The road ahead

There are a few things we’re still working on for the 5.0 series. We have bugs that we want to fix. We currently do not have binary packages for MinGW (as WebKit doesn’t yet work with it yet) and MSVC 2012 (you’ll need to compile from source), and we’ll work on delivering these as soon as possible. The current plan is to have a first patch level release, 5.0.1, some time before the end of January.

We’ll then be aiming for a Qt 5.1 release some time in Spring 2013, where we’ll mainly focus on stability and bringing modules such as Qt 3D and Qt Sensors into the Qt 5 base distribution. We also hope to be able to show some preview releases of the Qt ports for Android and iOS within the same time frame.

From there on, we will move over to a fully time based release schedule with feature releases twice a year.

Thanks

Finally, there should be some time to thank all the people that helped make the release happen.

A total of 427 people have contributed changes to the code base. Here are the pictures of some of them:

Many more have helped by reporting bugs, discussing with us, giving feedback, or simply by supporting the people that have been working on Qt 5.0.

Everybody at Digia has been working extremely hard the last couple of months trying to get the release together. We managed to completely restructure the documentation after the 2nd beta. People have been doing an amazing amount of testing and bug fixing. Pulling it all together was a lot harder then we all expected, but we managed to get the packages into shape in the end.

KDAB has been contributing a lot with features, bug fixes and reports. They did special Qt 5 bug fixing days. Many other people inside the community have worked equally hard.

This shows that a little more then one year after it’s launch, the Qt Project has turned into a great and fantastic community.

I’d like to thank each and every one of you. You all helped making this release happen.

Enjoy your Christmas holidays and I wish us all a happy and successful new year!

Qt 5.0 RC2 released

It’s been one week since we released the first Release Candidate for Qt 5.0 during the Qt Developer Days in Santa Clara. After evaluating the feedback and going through the list of reported bugs, we decided that RC1 wasn’t good enough for a final release.

We have been using the last week to fix a lot of the reported bugs, and are now happy to announce that we have a second release candidate available for testing. You can download it from http://qt-project.org/downloads. It is also available from the Digia customer portal for commercial licensees.

This release candidate looks a lot better then RC1. There are very few known issues with it and almost all P0 and P1 bugs got fixed. A lot of additional work has happened in fixing documentation, polishing the examples and making the whole installation experience smoother.

Once again, I’d like to invite as many people as possible to give the RC2 a try and report back any issues that you find. If everything goes well, we will hopefully be able to release Qt 5.0.0 final next week!

Qt 5.0 Release Candidate

I’m very happy to announce that the first release candidate for Qt 5.0.0 has just been released.

Since the release of the second beta around 4 weeks ago we’ve made tremendous progress in stabilizing Qt and getting all the remaining pieces in place. While we have over the last couple of weeks fixed hundreds of bugs in the code base, most of the focus has actually been on polishing the usability of the product. The product structure and feature set is pretty much what we already have announced with the second beta. But apart from pure bug fixes there are still a couple of things that are new.

We have been completely restructuring the Qt documentation to make it easier to access. Please have a look and check out the new docs. We hope that they will make it easier to find your way and access the information you’re searching for.

The examples have also received a lot of love to make sure it is easy to get started with Qt. They can be easily accessed, build and launched from Qt Creator’s Welcome screen.

A final set of a few additional API changes has also made it into the release candidate. This release fixes the API set for Qt 5.0. Between now and the final release we will only make very minor adjustments to the API.

All of these change classes and methods that have been introduced with Qt 5.0, and with thus not affect you if you are porting your application from Qt 4. The list of changes from Qt 4 are described in the changelog. We have worked hard to keep that set of changes as small as possible so that it is very easy to bring your application over to Qt 5.

We are feeling confident that the release candidate is getting pretty close to the Qt 5.0 final release and would thus like to invite you all to give it a try. Please use the time now to report any issues you find back to us. There are a few bugs and problems we know about. You can find those at the known issues page.

We’re aiming to move towards a 5.0.0 final release as quickly as possible now. If we don’t hear about or find any large issues with the release candidate, we hope to be able to release it as 5.0.0 in about a week from now. Otherwise, we are aiming at fixing the bugs that show up and release a new RC in maybe a week from now.

 

Enjoy!

Qt 5.0 Beta 2 is Out

I’m glad to announce that Qt 5.0 Beta 2 is now released, just in time for Qt Developer Days in Berlin. The beta puts us closer to the final release of Qt 5.0, which we anticipate to release by the end of the year.

A Full Release – Qt 5.0 Throughout

A lot of work has happened since the Beta 1 towards bringing Qt 5 closer to a final release. One of the biggest differences is that this Qt 5.0 release includes not only the Qt libraries, but also the tools. Qt Creator 2.6 based on Qt 5.0 is now bundled together with Qt 5.0 to make it a full complete release. It also helps us in testing and verifying the quality of Qt 5.

This release will only support Qt 5.0, but we will later examine whether and how we can add Qt 4.x support to it.

In addition, it shows that Qt 5 is a good and mature release with a very high degree of compatibility with Qt 4.x. Qt Creator can currently be built both against Qt 4.8 and 5.0 from a single code base. This proves that Qt 5.0 is almost fully source-compatible with Qt 4.8.

Qt 5.0 Functionality

With Qt 5.0 Beta 2, we have now finalized the list of modules and packages that will be part of the 5.0 final release. Qt 5.0 will contain the following libraries:

 

Qt Essentials

  • Qt Core
  • Qt Network
  • Qt Gui
  • Qt Sql
  • Qt Testlib
  • Qt Widgets
  • Qt Qml
  • Qt Quick
  • Qt Multimedia
  • Qt WebKit
  • Qt WebKit Widgets

 

Qt Add-ons

  • Qt Xml
  • Qt XmlPatterns
  • Qt Svg
  • Qt Concurrent
  • Qt Printsupport
  • Qt DBus
  • Qt OpenGL
  • Qt ActiveQt
  • Qt Graphical Effects
  • Qt Script
  • Qt Declarative
  • Qt Image Formats

 

Tools and other functionality

  • Qt Assistant
  • Qt Linguist
  • Qt Designer
  • Qt Translations
  • Qt Creator
  • Qt Documentation

 

As you can see, there is a lot of functionality included in Qt 5.0., but some modules like Qt 3D have been excluded from this release. However, they are still available from qt-project.org and you can use them together with Qt 5.0.

 

Known Issues

As this is a beta, it still has some known issues. First of all, there is still a major overhaul of the documentation planned for Qt 5.0 that didn’t make it into this beta, so you can still expect some larger changes in this area. Apart from that, there’s a lot of smaller known issues. An up-to-date list can be found at http://qt-project.org/wiki/Qt500beta2KnownIssues

 

Try it Out

Because this release bundles the libraries and the tools, it should now make it very easy for everybody to get started with Qt 5.0 and try it out on their own project. Please go ahead, try it out on your project and give us your feedback so that we can fix as many issues as possible for the final 5.0 release.

I encourage you to download Qt 5.0 Beta 2 from the http://qt-project.org/downloads site or from http://qt.digia.com/Try-Qt-Now/

If you are a Qt commercial customer, you can download the release via your Digia Qt customer portal.

 

Qt Developer Days 2012 Soon Here!

Even with all the changes around Qt over the last year, there are some constants that we have. One of them is Qt Developer Days. I’m really happy, that we will also this year have this great event in both Berlin and Santa Clara. This event has always been a great place to meet many people from all over the world who use Qt, listen to lots of great presentations and in general have a good time.

I’m really looking forward to this year’s Dev Days as this year, for the first time, it is organised by KDAB, ICS and Digia. I’m sure the event will be as exciting as ever, and I’ve seen lots of cool presentations in the line-up.

The Berlin event is from the 12-14th of November and the event in Santa Clara is from the 5-7th of December.

You can have a look at the Berlin program, directly here:
http://qtconference.kdab.com/node/25

The U.S event agenda will be up soon.

For more info and registration have a look at http://www.qtdeveloperdays.com.

I really hope to see you and talk to as many Qt users as possible during these events!

Towards Qt 5.0

It’s been now some days since we released the Qt 5 beta, and thus it is time to look ahead to what’s going to happen in the next few months and the plans for the Qt 5.0.0 final version release.

Moving to Digia

The first important thing is that the planned transfer of Qt from Nokia to Digia is anticipated to be finalized in Q3. I personally have also chosen to join Digia and continue my work on Qt from there. Having now had quite a few talks with Digia, I believe this is going to be a great opportunity both for Qt and for the development teams in Oslo and Berlin.

From all I can see, Digia has a solid, long-term strategy with Qt, focusing strongly on the product, pushing for Qt 5 and making Qt the best possible development tool out there. This is a large acquisition for Digia, which underlines how strategic they believe Qt will be for them in the future.

Digia wants to grow the Qt ecosystem together with other players in the market. They understand the importance of keeping that ecosystem unified. They also understand how important dual licensing is for the Qt ecosystem.

The teams planned to transfer from Nokia will be a significant addition to the business unit that is currently selling Qt Commercial. The people coming from Nokia are, to a large extent, developers and the former Nokia teams will actually form the majority of the development team in Digia.

Of course, there will be changes for the Nokia Qt people joining Digia, but I do believe that they will be changes for the better. These changes will include a broader focus on customer needs and a more immediate feedback cycle from our customers to development. This is something I’m personally looking forward to.

But some things are planned to stay the same. We aim to continue the strong focus on product development and pushing the boundaries of what can be done with Qt. Qt 5 is planned to be be the central focus of most of our work, both short and longer term.

Finalizing the Qt 5.0 release

One of the most important things to do in the short term now is to finalize Qt 5. The Qt 5 beta has now added binary packages for the main platforms, but it is still missing some pieces. We are aiming at including Qt Creator into the Qt 5.0 release and creating a package that is similar to the Qt SDK packages we have released for 4.x.

We had a workshop on Monday in Oslo trying to identify the work that remains to be done. Apart from general bug fixing a couple of items clearly showed up, and we will strongly focus on these for the next couple of weeks:

  • Documentation

    While the individual class documentation is in an OK state, lots of work remains to be done to tie it all together. We are lacking overview documentation, intros to Qt and the different modules, some getting started help and a good landing page. Making the difference between Qt Essentials and Add-ons clear, as well as cross-referencing between modules still requires work. We have now a team in Oslo that will focus on putting all of this in place.

  • Examples and Demos

    A lot of the existing examples in Qt have been there for a long time. We will go through the list and do a cleanup of the examples, probably removing a large part of them in the process and focusing on having a small but high quality set of examples available for Qt 5.0.

  • Finishing and testing our reference platforms

    This is mainly bug fixing and testing, but nevertheless extremely important. On some platforms we will need to do some more work than on others.

    On Windows, we will change the default build to use ANGLE (OpenGL on top of DirectX) to avoid issues with bad OpenGL drivers and remote desktop. In addition this will make the Multimedia and WebKit integration easier and with improved performance. Of course, building against the regular desktop OpenGL drivers will still be supported.

    On Mac and Linux, there’s also work required to finish the multimedia integration as well as many other smaller issues.

    WebKit 2 and the QML module for WebKit have been disabled for the beta. The WebKit team is now very close to having this work on all reference platforms.

  • Qt Creator

    We are aiming at adding Qt Creator to the binary packages. The Berlin team will focus on making sure Qt Creator will work as smoothly as possible together with Qt 5.

  • Packaging

    Finally, we need to pull all the pieces together into a decent set of packages. What we have seen from the beta is that one can easily underestimate that part of the work, so we will need to have some extra focus in this area.

I would like to aim for a second beta as soon as possible, but only once most of the issues mentioned above are resolved. A realistic time frame for this second beta release is probably in around 4-6 weeks from now. After that we will quickly push for a release candidate and a Qt 5.0 final release.

Longer term

As soon as the team has moved to Digia, and we start having some time again in parallel to finishing Qt 5, we plan to focusing also on new things. Digia has already publicly communicated some areas they consider important, such as an Android and iOS support. In addition, the teams in Berlin and Oslo have been coming up with many good ideas.

We are now in the process of sorting through these ideas and prioritizing them. Our goal is to be as open and transparent as we can be about what we will be doing, as well as what we’re not going to do. In this way, we aim to avoid duplicating work and give everybody the chance to participate in the Qt Project.

Qt 5 Beta is here

The Qt 5 Beta is now available as the first major release under the new Qt Project umbrella. A big thank you goes out to all who contributed to this milestone. With this Qt 5 beta release, I would also like to invite everybody interested to go, try, and experience this next major version of Qt. Your feedback now will be very important in making the final release of Qt 5.0 as good as possible.

It’s now 15 months since we announced the start of Qt 5 development, and I am really happy to see what has been achieved during this time. All of the major architectural changes that we planned for have been implemented. At the same time, the community around Qt and qt-project.org has seen a nice and healthy growth.

Qt 5 will make it easier and faster to create:

  • Smooth, accelerated graphics performance with limited resources. Qt 5 makes better use of the GPU to deliver better performance on inexpensive hardware. For example, using Qt 5 you can achieve 60 fps performance on a $35 single-board computer like Raspberry Pi. – See the Qt on Pi project for more info.
  • Advanced UIs and applications written in QML and JavaScript. See the Qt Media Hub as an example
  • Powerful apps connected to the web

High-performance Apps and UIs

Qt 5 addresses two core challenges developers face when creating high-performance apps and UIs:

  1. Better tools to design the UIs and
  2. Better rendering performance to execute your vision.

The new extensions and APIs to the QML language make it easier to create rich and fluid apps and UIs for touch screen devices in addition to supporting keyboard input methods. Qt 5′s updated WebKit and Qt Quick modules support out-of-the-box touch interaction for smooth user experiences.

The new graphics stack sports an all-new rendering pipeline using an OpenGL based scene graph that is fully optimized for Qt Quick. This makes it trivial to integrate OpenGL-based content, such as shader effects or particles. Text rendering is also fully hardware accelerated, giving you faster graphics and lower power consumption. As a result, Qt 5 delivers the same 60 fps smoothness seen on high-end smartphones even when executed on inexpensive hardware like the Raspberry Pi.

Providing Source Compatibility and Continuity – Porting and QWidgets

A lot of effort has gone into making the transition of your code base and skill set from Qt 4 to Qt 5 as easy as possible and to keep as much source compatibility with Qt 4.x as we can. As an example we currently have Qt Creator compiling and running against Qt 4.x and Qt 5 using the same code base.

You can find links to detailed porting instructions on the Qt 5 beta page or look at some examples of KDAB’s porting efforts.

Updating your code base is primarily a process of updating your projects’ .pro files, to change header file includes and add used modules. Qt 5 provides a script that facilitates this task. In addition, code that integrates with native windowing system functionality of the underlying platform will need some adjustments.

While new UI designs benefit from the updated QML for mobile and embedded applications, it is also important to notice that existing widget-based designs remain viable. Widget-related APIs continue; QWidget and all derived classes are a core part of Qt 5 on the Desktop – and will remain so.

New APIs and modules

In addition to the changes to the internal architecture, a lot of new APIs have also found their way into Qt 5. Many new classes appeared in QtCore, providing support for JSON, mimetype recognition, standard paths and many other things.

The OpenGL support is now an integral part of QtGui and has received some nice improvements. QWindow provides a better abstraction for top-level windows then the old QWidget.

A couple of new modules have been added to the scope of Qt 5. In particular, the differentiation between Qt and Qt Mobility that existed in Qt 4.x has been removed. Instead we now have a more modular structure and each module (a shared library or QML import) is now classified as either being part of the Qt Essentials or an add-on.

This new structure will make it easier in the future to integrate modules providing new functionality into the Qt Product offering, and allow for example KDE to provide their frameworks as add-ons to Qt.

Greater opportunity

In addition to delivering the best development environment possible, it is important that Qt increases your opportunity to get your projects in front of a bigger audience.

With Qt 5, support for multiple operating systems continues. The QPA abstraction layer makes the task of porting to new platforms easier and more seamless then ever before. We are already seeing a lot of work going into Qt 5 to implement a full port to QNX and Blackberry 10. Digia has already announced their plans to port Qt 5 to Android and iOS.

In addition, a lot of effort and contributions have gone into especially improving the use case for embedded developments on Linux. This helped the strong growth/up-take we witnessed within Qt for Automotive, IPTV/ STB and other IP comms manufacturers for current and next gen infotainment systems.
Discussions regarding what additional improvements Qt 5.1 will bring to the desktop use case and how quickly i.e. we can integrate Qt desktop components are ongoing and were also part of the sessions that ran during 3 days when close to 200 contributors attended the Qt Contributor Summit in Berlin during the end of June.

Known issues

While we are happy with the current state of the beta in most places, there are a few known issues that you might want to check out from our Known-Issues page. Most notably, you will need decent OpenGL drivers on Windows for Qt Quick to work, and there are issues remaining with Qt Multimedia on platforms other than Linux.

We expect these issues to get resolved for the Qt 5.0 final, where we will by default use ANGLE to layer OpenGL on top of DirectX (the option to use the native OpenGL support on Windows remains of course) and work on the remaining Multimedia issues.

Summary

One thing that is becoming very visible now is how much the start of the Qt Project and move to Open Governance helped in improving Qt. Over the last year, we have managed to create a very active and passionate community of developers around Qt, and many of the improvements we are now seeing in Qt 5 would not have been possible without all this efforts.

As an example, I’d like to mention all the improvements that flowed from the KDE libraries back into Qt 5. These will actually make it possible to have a more modular approach for KDE applications and fully remove the differentiation between a KDE and a Qt app

I am very proud of what has been achieved with Qt 5. A big thank you goes to everybody who has in some way contributed to bringing Qt 5 to where it is now. Let’s also take a bit of time to celebrate all the hard work that has gone into this release, as the first major beta released under the new Qt Project umbrella.

Lars Knoll

Qt 5, C++ and Qt Widgets

We have seen the many questions and the concerns raised about our commitment to C++ and QWidget in Qt 5. I thought now would be a good time to address some of these concerns in this post.

The post on the Qt 5 alpha was focused on the new things we enable and add with Qt 5.

Let me just state it very clearly here:

QWidget and all derived classes are a core part of Qt 5 on the Desktop.

You can continue writing your application in exactly the same way as you have been doing with Qt 4.x.

We have promised to try to keep as much source compatibility with Qt 4.x as we can. And of course this includes QWidget and your application written in C++. This is not going away. Yes, the Qt Widgets module we have in Qt 5 is right now marked as ‘done’, which means we don’t have anybody actively working on new features for the module at this point in time. But this can change any day if someone has some interest or need to do more active development in this area.

What we did with Qt 5 is to add a new way to do applications with QML. I personally believe that over time we will see more and more apps being written that way, as I believe it is the better solution in the long term.

New user interfaces such as the Windows 8 Metro UI are not things we could simply add to our existing QWidget infrastructure. Adding support for the kind of animations used in these user interfaces is extremely difficult using QWidgets, as they were designed for the mostly static user interfaces that predominated until a couple of years ago.

The fluid animated user interfaces that are already there on Devices such as smartphones and tablets are now also starting to appear also on desktops. And they are simply not implementable using the QWidget infrastructure.

This implies that we needed to do something new here. And QML/Qt Quick was the answer we came up with to solve this problem. That’s why we’re investing in that area.

Our experience with QML over the last years has shown us that it is the superior technology for building UIs in the long term. If you want, you can simply use it as a more powerful replacement to .ui files. But you can also write some application logic in there using Javascript if you want.

It really is up to everybody what they make out of the options being given by Qt 5, and how they best like to use them.

C++ is and will stay our main programming language.

We have done significant work for Qt 5 adding many new C++ APIs. We have added support for C++11 in many places. And we’ll continue to do so, because larger scale applications written with Qt will be mostly written in C++ for a long time to come. And there’s nothing bad about this.

What we did with Qt 5 is to add another option into the mix. We want to make the usage of Javascript supported as well as C++ is supported. We are not making it the superior way or even the only way. That is a good thing, as it opens up new options for how you write your application.

If you want, you can do smaller pieces of application logic inside QML. It allows to do some rapid prototyping that can then be replaced by C++ in the final implementation. It gives you abilities to do application scripting. And for many apps it also gives you the option to write a big part of it in QML and Javascript.

Summary

With Qt 5, if you want to use Qt as you have always used it, please go ahead. It’s a fully supported way of doing things.

But I do believe that we will need more then what we have in Qt 4 for the longer term future. The expectations towards application UIs are changing drastically, especially when creating consumer-facing apps.

We need to have solutions available if we want Qt to stay relevant. That’s what Qt 5 is all about.

Cheers,
Lars

The Qt Blog

Welcome to the new Qt blog! We have consolidated all the blog posts from the Qt Labs Blog with the posts from the Digia Qt Commercial blog. Our intention is to provide you with one area for all Qt development posts from our Qt experts.

As Qt enters a new era, we are working diligently to provide you with an ever-growing Qt Blog that includes projects, awesome ideas, tips and tricks and product info from our pool of very clever Qt developers.

This blog will be transforming as we move forward, so keep your eyes peeled for new developments.

Recent Comments

Archives

Categories