Qt 5 thoughts
Qt 4.0 was released in June 2005, almost six years ago. Much has changed in the software industry over the years. At that time, application development was mainly on the desktop, but now mobile devices connected to the network are becoming increasingly popular. UI technology has moved from static widgets to smooth touch. Starting with Qt 4.0, we have released seven minor versions of Qt, following the needs of developers and users, for example, by developing Qt Quick. With the growing Qt user base, there is a growing need for embedded, mobile applications and UI developers.
In addition, in the future, to be a leading framework for developers in several industries, Qt needs to be continuously updated and developed. Qt 4 was an evolution, so I wondered what the next versions of Qt might look like from a technical point of view. In recent years, we have been working to create the basis for the next major version. I see Qt Quick, QML Scenegraph and the Lighhouse project in combination with the increased emphasis on Qt Webkit as the foundation we plan to use to move to the new major release of Qt.
Given that Qt is openly managed, I would like to share my thoughts with the Qt community to start discussions on the technical architecture of Qt 5.
')
In Qt 5, we plan to make some changes to the API and leave behind restrictions from the past to make it better in the future. For those of you who have been with us when switching to Qt 3 on Qt 4, we do not plan to repeat such difficulties of switching to Qt 5. We believe that we can maintain compatibility in most cases, but the loss of binary compatibility cannot be avoided. We will do everything to avoid violating any fundamentals and make the transition from Qt 4 to Qt 5 very simple for most applications.
Qt 5 will focus on a small set of operating systems / platforms (i.e., Wayland and X11 platforms on Linux, Mac and Windows). The total number of platforms will depend on the efforts of the open community nested in Qt. Other operating systems currently supported by Qt 4 (especially commercial UNIX systems) will not be the focus for Nokia. The goal of the Qt 5 project is to provide the best functionality on each platform, which means that Qt will begin to offer more differentiated features on different operating systems, while at the same time offering effective reuse of most of the code on different platforms.
Another major change in Qt 5 will be the development model. Qt 4 was developed primarily in Trolltech and Nokia, then published to the developer community. Qt 5 we plan to develop openly, as a project with initially open source. There will be no differences between Nokia developers and other contributors.
If you or your company would like to participate in the development of Qt 5, please join the Qt Developer Summit in Berlin from 16 to 18 June. This is the main place where we would like to discuss with you plans and ideas for Qt 5.0 and 5.1. Some of us will also be at the Ubuntu Developer Summit this week and at the MeeGo conference later this month.
Qt 5 should be the basis for a new way of developing applications. While all the power of Qt natives in using C ++, it is proposed to focus on the transition to a model where C ++ is used mainly to implement modular backend functionality for Qt Quick.
In Qt 5, we have to put Qt Quick in the center of Qt without damaging the existing code developed for Qt 4. This will be rather a restructuring, which will allow us to change the way applications are developed in the future.
Although traditional Qt / C ++ applications will continue to work with Qt 5, there will be some fundamental changes in HOW applications can and will be written.
It should be expected that over time all interfaces will be written in QML. The core JavaScript in the Qt community, and we should expect most application logic and even entire applications to be written in JavaScript, not C ++. It is expected that many application developers will now start with QML and JavaScript, and will implement functions in C ++ only when required. In some cases, the full power of the C ++ API offered by Qt can be used to implement time-critical and complex functionality applications.
While we offer support for a QWidget-based programming model and a set of APIs for compatibility, in the long term, we also see QML as the future of user interfaces on the desktop. The solution here is a QML-based set of components that integrates with native styling APIs on desktop platforms .
Qt Components and Qt Mobility will now become an integral part of the Qt platform, rather than modules with special status.
The fact that we don’t want to overly change the fundamentals of Qt and the fact that we want to make the transition of existing applications to Qt 5 simple makes us be careful with the number of changes and the existing code base. Most of the changes we have already proposed to you, as well as we have begun work on restructuring our code base into a new modular structure, where each dynamic library is in its own repository. We believe that we should remove some very rarely used APIs that are kept for compatibility, but stop the subsequent development. We also believe that the beta versions will be available by the end of the year and the final release of Qt 5.0 will be released in 2012.
Last week, the Qt SDK was released with updates that are planned to be used in the coming year for target devices with Nokia Symbian and MeeGo. Qt 5.0 focuses around the next generation of applications and user interfaces, but there should be no serious difficulties with switching to this version.
For those of you who are interested in the details, here is a link to an official document that describes some of the ideas in more detail. None of this document is finalized, but it reflects our current trends and thoughts.
You can follow our work in the Qt repositories . We intend to maintain a master branch suitable for use at any time, at least on Linux with Wayland and X11 (xcb lighthouse plugin).
It is possible that some functions will not be fully available in Qt 5.0 and will only appear over time in future versions, but we hope that there will be no significant regression of functionality for Qt 4.8 (yes, we intend to release another intermediate version in the Qt 4 series .x over the next few months!). When developing Qt 5, we must do everything we can to maintain compatibility with Qt 4, so that porting applications to Qt 5 is as simple as possible. So, if you want to help or participate in the development of Qt 5, we are waiting for you at the Qt Developer Summit in Berlin this June.
In addition, in the future, to be a leading framework for developers in several industries, Qt needs to be continuously updated and developed. Qt 4 was an evolution, so I wondered what the next versions of Qt might look like from a technical point of view. In recent years, we have been working to create the basis for the next major version. I see Qt Quick, QML Scenegraph and the Lighhouse project in combination with the increased emphasis on Qt Webkit as the foundation we plan to use to move to the new major release of Qt.
Given that Qt is openly managed, I would like to share my thoughts with the Qt community to start discussions on the technical architecture of Qt 5.
')
Goals of the next major Qt version (Qt 5)
- Improve the use of the GPU, allowing you to create smooth (and accelerated) graphics, even with limited resources;
- Make the creation of modern applications and user interfaces easier and faster (using QML and JavaScript);
- Make applications connected to the Web more powerful and better, that is, give the ability to easily embed web content and web services into any Qt application.
- Reduce the complexity and amount of code required to maintain and implement ports.
Make it easy to transition from Qt 4 to Qt 5
In Qt 5, we plan to make some changes to the API and leave behind restrictions from the past to make it better in the future. For those of you who have been with us when switching to Qt 3 on Qt 4, we do not plan to repeat such difficulties of switching to Qt 5. We believe that we can maintain compatibility in most cases, but the loss of binary compatibility cannot be avoided. We will do everything to avoid violating any fundamentals and make the transition from Qt 4 to Qt 5 very simple for most applications.
Qt 5 will focus on a small set of operating systems / platforms (i.e., Wayland and X11 platforms on Linux, Mac and Windows). The total number of platforms will depend on the efforts of the open community nested in Qt. Other operating systems currently supported by Qt 4 (especially commercial UNIX systems) will not be the focus for Nokia. The goal of the Qt 5 project is to provide the best functionality on each platform, which means that Qt will begin to offer more differentiated features on different operating systems, while at the same time offering effective reuse of most of the code on different platforms.
Open source development with you with strong Nokia support
Another major change in Qt 5 will be the development model. Qt 4 was developed primarily in Trolltech and Nokia, then published to the developer community. Qt 5 we plan to develop openly, as a project with initially open source. There will be no differences between Nokia developers and other contributors.
If you or your company would like to participate in the development of Qt 5, please join the Qt Developer Summit in Berlin from 16 to 18 June. This is the main place where we would like to discuss with you plans and ideas for Qt 5.0 and 5.1. Some of us will also be at the Ubuntu Developer Summit this week and at the MeeGo conference later this month.
Overview
Qt 5 should be the basis for a new way of developing applications. While all the power of Qt natives in using C ++, it is proposed to focus on the transition to a model where C ++ is used mainly to implement modular backend functionality for Qt Quick.
In Qt 5, we have to put Qt Quick in the center of Qt without damaging the existing code developed for Qt 4. This will be rather a restructuring, which will allow us to change the way applications are developed in the future.
Although traditional Qt / C ++ applications will continue to work with Qt 5, there will be some fundamental changes in HOW applications can and will be written.
It should be expected that over time all interfaces will be written in QML. The core JavaScript in the Qt community, and we should expect most application logic and even entire applications to be written in JavaScript, not C ++. It is expected that many application developers will now start with QML and JavaScript, and will implement functions in C ++ only when required. In some cases, the full power of the C ++ API offered by Qt can be used to implement time-critical and complex functionality applications.
While we offer support for a QWidget-based programming model and a set of APIs for compatibility, in the long term, we also see QML as the future of user interfaces on the desktop. The solution here is a QML-based set of components that integrates with native styling APIs on desktop platforms .
Four major architectural changes
- Restructuring our graph stack
We will put Qt Quick and QML Scenegraph at the center of our new graphical architecture. QPainter will still be available and very useful for many things, but it will not be used for the main user interface. Qt will require OpenGL (ES) 2.0 to work. QWidgets will be in the hierarchy on top of the scene graph (and not the scene graph on top of QWidgets, as is now done in Qt 4). - All Qt ports will be based on the Lighthouse.
The Lighthouse project was launched with the goal of providing a better way to abstractly integrate window systems than we are currently using. It is currently reaching maturity in Qt 4.8, and we intend to use the Lighthouse for all Qt ports in Qt 5.0. - Modular repository structure
A lot of work has been done in recent weeks, and you can see the results in the new Qt modular repositories . Modularization will facilitate and accelerate the joint development of Qt. - Separate all QWidget related functions into a separate library
So far, classes based on QWidget are extremely important for existing applications, but over time we will approach the model where all interfaces are created in QML. Allocating QWidget-related functionality to your own library is a good measure to achieve a clean Qt 5 architecture in the long run.
Qt Components and Qt Mobility will now become an integral part of the Qt platform, rather than modules with special status.
Beta versions are available by the end of 2011. The final release in 2012
The fact that we don’t want to overly change the fundamentals of Qt and the fact that we want to make the transition of existing applications to Qt 5 simple makes us be careful with the number of changes and the existing code base. Most of the changes we have already proposed to you, as well as we have begun work on restructuring our code base into a new modular structure, where each dynamic library is in its own repository. We believe that we should remove some very rarely used APIs that are kept for compatibility, but stop the subsequent development. We also believe that the beta versions will be available by the end of the year and the final release of Qt 5.0 will be released in 2012.
Last week, the Qt SDK was released with updates that are planned to be used in the coming year for target devices with Nokia Symbian and MeeGo. Qt 5.0 focuses around the next generation of applications and user interfaces, but there should be no serious difficulties with switching to this version.
Help us speed development
For those of you who are interested in the details, here is a link to an official document that describes some of the ideas in more detail. None of this document is finalized, but it reflects our current trends and thoughts.
You can follow our work in the Qt repositories . We intend to maintain a master branch suitable for use at any time, at least on Linux with Wayland and X11 (xcb lighthouse plugin).
It is possible that some functions will not be fully available in Qt 5.0 and will only appear over time in future versions, but we hope that there will be no significant regression of functionality for Qt 4.8 (yes, we intend to release another intermediate version in the Qt 4 series .x over the next few months!). When developing Qt 5, we must do everything we can to maintain compatibility with Qt 4, so that porting applications to Qt 5 is as simple as possible. So, if you want to help or participate in the development of Qt 5, we are waiting for you at the Qt Developer Summit in Berlin this June.
Source: https://habr.com/ru/post/118964/
All Articles