And let's feel Qt5
The release of the first alpha Qt5 is not far off, but why should we wait for this moment if we can plunge right into the near future with its QtQuick2, V8 and qpa?
The easiest way is to build a linux version of Qt, which is why we’ll build it.
')
Everything is trite here, we find a directory convenient for this purpose and we command:
Immediately you should pay attention to the fact that the team will work suspiciously quickly. So it should be! The repository actively uses submodules that are not downloaded during cloning. Now you need to initialize them.
And we can safely go to drink tea. Sources weigh a lot! And sometimes it happens that gitorious breaks the connection, then restart the init to the force key.
update:
Vass said that it’s not possible to completely turnip a turnip and download the source code faster.
README recommends the following command:
But I would also add the -release and -fast key in order to quickly get something that can be touched.
Now just command make with the number of kernels and go about your business. I do not advise to turn on the silent flag, it is sometimes buggy!
You can see that some of the classes from QtGui have moved to QtWidgets, while now using QWindow instead of QWidget to create the window. There are no more macros like Q_WS_X11 or Q_WS_WIN32, but the macro Q_WS_QPA appears. Accordingly, the approach to window systems has changed in general; now they are switched not at the compilation stage, but at the launch stage. This should be remembered when porting your applications to Qt5. To switch window systems, you can use the -platform switch
For feeling examples, I added a Qt5 profile to QtCreator:
Now we can safely collect them, run them, and also try to build our old programs with Qt5. A couple of examples from the heat of the heat:
It looks like nothing has changed in comparison with Qt4, although inside it already works somewhat differently.
For these purposes, there is the qmlscene utility, let's run with it a couple of examples:
Unfortunately, without a video, it is impossible to appreciate the beauty of new features; for these purposes, it is better to search for videos on YouTube. In general, I want to say that while QtQuick2 in Linux works somewhat strangely, in the first place I will not say that it works smoother than QtQuick1, in the second, some demos do not work or fall. What is the reason for this, with the dampness of the video drivers or the scene graph itself is not yet clear, but on the video with rapsberry everything works smoothly. I did not delve into the API changes, but immediately noticed the presence of shaders and the canvas API. It is now even easier to make applications without resorting to C ++ for this.
To build a QtWayland module, you need to independently execute the qmake and make commands in its directory. At the same time making sure that we use qmake from Qt5. After that, a plug-in backend for wayland and several examples of wayland composers are assembled. The most interesting of them is qml-compozitor, whose code is entirely written in qml! It looks like this at the moment:
And falls at any opportunity. Inside the weston, Qt applications work much more stable, but they also like to fall when trying to resize a window. In general, the beginning of an interesting, but the work is still no end.
To whom it is interesting, you can try to collect this demo, it works great, even now do an image editor based on it.
Qt platform abstraction, definitely, a big step forward for writing cross-platform applications, but you need to get used to it and have to wean from the old approach with # ifdefs. Well, you have to accept the fact that the definition of the platform will be in runtime, and not at compile time, which, if you design the application incorrectly, will lead to performance losses.
The division into modules has become much more logical. Now there is no separate QtMobility project, all its developments are in the master branch. And to write Qt Quick applications, you no longer need to pull a very thick widget library.
Qt Scene Graph is still very raw and you need to be more careful and careful with it.
Qt Wayland is still very raw, but it shows us interesting ideas for writing composers. It is likely that on its basis more cool projects will appear.
The process of porting applications to Qt5, basically, is reduced to a simple reassembly of pro files and the addition of the widgets module there and in the inclusive fix. The horrors of moving level Qt3> Qt4 no!
The easiest way is to build a linux version of Qt, which is why we’ll build it.
Required dependencies for assembly:
- git - all raws are now mirrored on gitorious and therefore without git you simply can't get the source code
- build-essential - a set of make, gcc and related utilities
- xcb - to build x11 backend header files and libraries are required. Please note that Qt5 moved to xcb instead of xlib!
- wayland - to build wayland backend
- mesa - without openGL support, Qt will not be built or will not work! We need at least software support at the level of llvmpipe.
- time - there is a lot of source code, either a powerful computer or a lot of time
')
Getting the source
Everything is trite here, we find a directory convenient for this purpose and we command:
$ git clone git://gitorious.org/qt/qt5.git qt5 Immediately you should pay attention to the fact that the team will work suspiciously quickly. So it should be! The repository actively uses submodules that are not downloaded during cloning. Now you need to initialize them.
$ cd qt5 $ perl init-repository And we can safely go to drink tea. Sources weigh a lot! And sometimes it happens that gitorious breaks the connection, then restart the init to the force key.
update:
Vass said that it’s not possible to completely turnip a turnip and download the source code faster.
I want to add that if a webkit is fundamentally not important to you, then it is better to add the --no-webkit key to the init-repository , so you will save yourself from a long wait “when this fat infection will download” and from questions like “why this fat infection is not going to. "
Assembly:
README recommends the following command:
$ ./configure -prefix $PWD/qtbase -opensource But I would also add the -release and -fast key in order to quickly get something that can be touched.
Now just command make with the number of kernels and go about your business. I do not advise to turn on the silent flag, it is sometimes buggy!
Let's see what we did:
You can see that some of the classes from QtGui have moved to QtWidgets, while now using QWindow instead of QWidget to create the window. There are no more macros like Q_WS_X11 or Q_WS_WIN32, but the macro Q_WS_QPA appears. Accordingly, the approach to window systems has changed in general; now they are switched not at the compilation stage, but at the launch stage. This should be remembered when porting your applications to Qt5. To switch window systems, you can use the -platform switch
For feeling examples, I added a Qt5 profile to QtCreator:
Now we can safely collect them, run them, and also try to build our old programs with Qt5. A couple of examples from the heat of the heat:
It looks like nothing has changed in comparison with Qt4, although inside it already works somewhat differently.
We try QtQuick2 and the praised Scene Graph
For these purposes, there is the qmlscene utility, let's run with it a couple of examples:
Unfortunately, without a video, it is impossible to appreciate the beauty of new features; for these purposes, it is better to search for videos on YouTube. In general, I want to say that while QtQuick2 in Linux works somewhat strangely, in the first place I will not say that it works smoother than QtQuick1, in the second, some demos do not work or fall. What is the reason for this, with the dampness of the video drivers or the scene graph itself is not yet clear, but on the video with rapsberry everything works smoothly. I did not delve into the API changes, but immediately noticed the presence of shaders and the canvas API. It is now even easier to make applications without resorting to C ++ for this.
We feel QtWayland
To build a QtWayland module, you need to independently execute the qmake and make commands in its directory. At the same time making sure that we use qmake from Qt5. After that, a plug-in backend for wayland and several examples of wayland composers are assembled. The most interesting of them is qml-compozitor, whose code is entirely written in qml! It looks like this at the moment:
And falls at any opportunity. Inside the weston, Qt applications work much more stable, but they also like to fall when trying to resize a window. In general, the beginning of an interesting, but the work is still no end.
To whom it is interesting, you can try to collect this demo, it works great, even now do an image editor based on it.
General impressions
Qt platform abstraction, definitely, a big step forward for writing cross-platform applications, but you need to get used to it and have to wean from the old approach with # ifdefs. Well, you have to accept the fact that the definition of the platform will be in runtime, and not at compile time, which, if you design the application incorrectly, will lead to performance losses.
The division into modules has become much more logical. Now there is no separate QtMobility project, all its developments are in the master branch. And to write Qt Quick applications, you no longer need to pull a very thick widget library.
Qt Scene Graph is still very raw and you need to be more careful and careful with it.
Qt Wayland is still very raw, but it shows us interesting ideas for writing composers. It is likely that on its basis more cool projects will appear.
The process of porting applications to Qt5, basically, is reduced to a simple reassembly of pro files and the addition of the widgets module there and in the inclusive fix. The horrors of moving level Qt3> Qt4 no!
Source: https://habr.com/ru/post/137808/
All Articles