I have seen so many documentation about Qt Embedded and Qt for Desktop. But not clear about the difference. Can anybody please explain the differences?
Qt for DEsktop LInuxQt/X11 is built on top of the x11 window system, but Qt for Embedded Linux provides its
own window system and has therefore lower RAM and ROM requirements. With
Qt for Embedded Linux, applications will access the display directly for optimal
graphics performance. Nonetheless, the API for developing applications is the
same for Qt/X11 and Qt for Embedded Linux.
As kernel maniac said, Qt for Linux is built on top of the X11 server. Qt for Embedded Linux instead provides its own Window System names QWS. With respect to X11 it is smaller in memory and draws directly to the framebuffer or might take advantage of other libraries to write, like DirectFB.
With respect to X11 it is far less advanced and it is difficult to add hardware acceleration to it. I suppose this is one of the main reasons why they dropped completely Qt on Embedded Linux in Qt 5.0. So consider that it is not available anymore. It is replaced by drivers implemented using QPA.
QT Embedded is desigined in order to build applications for embedded systems .
If you don't know what that is you can click here .
Qt for Desktop is used to deploy applications to the popular operating systems such as Linux, Windows.
Currently (Qt 4.8.3) the two links for Linux/X11 and embedded Linux point to the same file: http://releases.qt-project.org/qt4/source/qt-everywhere-opensource-src-4.8.3.tar.gz
I suspect there used to be differences (maybe from when Digia was responsible for creating a patched Qt for certain platforms?), but that that is no longer the case. Looking at the Qt archive (ftp://ftp.qt.nokia.com/qt/source/), it appears that a different, specific 'embedded' distribution of Qt ended after 4.5.x.
Related
I have been working with QML for a couple of weeks now. But now a new requirement has risen where I have to check whether I can run QT5 in an embedded device for my project. I need this for my GUI related operations. The device has an ARM processor (Intel ARM920T-PXA27x processor to be exact) with 64 MB RAM. 32 MB will be taken up for the OS and the rest will be available for application and QT.
I have to check whether this is possible. I have googled for some references and unable to find a suitable answer to my requirement with QT5. I need the GUI libraries but my project does not have advanced graphical requirements like swiping or animations. It contains basic controls like texts, buttons and lists/grids. Since I am new to QT especially to this part, I would like to hear whether
1) Is this a viable option and should I keep digging more into this? Any feedback would be welcome to know if it's worthy to spend time to attempt this or if it's a lost cause.
2) If there are options, could you point me in the right direction to look more into this?
It depends on the OS you are running on your SOC.
It's definitely possible when running Linux. You can e.g. use Qt Lite for configuring a minimal static build of Qt. Then you deploy your statically linked application to the device. You can check this blog post for experiences with Qt Lite.
One possibility is to go with Qt for Device Creation for the whole embedded Linux based software stack which boots to a UI implemented with Qt technologies.
I'm developer on Windows and I have some experiences on WinAPI programs.
As far as I know, there are two ways to draw on Windows, call GDI (includes wrapper of GDI like GDI+) to do traditional drawing or call some APIs like DX or OpenGL to draw use GPU.
But what other things like Qt are? Does Qt calls GDI finally to draw something? Or it just has its own way to draw directly?
I just want to know its theory in general.
Qt widgets use custom software renderer (custom raster engine) - it's not GDI from what it seems.
https://doc.qt.io/qt-5/topics-graphics.html
every widget inherits from QPaintDevice you can check the type of paint device: https://doc.qt.io/qt-5/qpaintengine.html#Type-enum
QtQuick seems to be using ANGLE (will convert ogl calls to d3d on windows) / pure OpenGL - https://blog.qt.io/blog/2017/01/18/opengl-implementation-qt-quick-app-using-today/
From the looks of it, since QT 4.0 they had changed the use of GDI and replaced it with some other internals that might improve portability, if you wish, QT is open sourced, so you may look at the code to understand QTGUI.dll internals.
I do not know this in practice, but the answer at http://qt-project.org/forums/viewthread/33565 seems reliable.
UPDATE: This page seems to be more accurate: http://qt-project.org/wiki/Qt-5-on-Windows-ANGLE-and-OpenGL
Qt 5 on Windows can be configured to use either OpenGL drivers, or
DirectX drivers through the ANGLE library. What you want depends on
your use case. The Qt project offers binary installers for both
variants. OpenGL
OpenGL (Open Graphics Library) is a wide spread industry standard
[opengl.org] for rendering 2D and 3D computer graphics. It’s the
de-facto standard for hardware-accelerated graphics operations on Mac
OS X, Linux, and most embedded platforms.
OpenGL ES 2.0 (Open Graphics Library for Embedded Systems) is a
stripped-down version of OpenGL for use on embedded systems, which is
missing some functions.
The Qt Quick 2 stack in Qt 5 is based on OpenGL, and requires OpenGL
3.0 (alternatively OpenGL 2.x with the framebuffer_object extension) or higher or OpenGL ES 2.0. The Qt OpenGL module [qt-project.org]
requires OpenGL 1.3 or later. OpenGL on Windows
Although Microsoft Windows has native support for OpenGL since quite
some time, the supported standard version (version 1 without any
drivers installed) is too limited for Qt . Newer versions are
generally available through custom graphics drivers, but require users
to install them. Also, the quality of the OpenGL support by some
drivers is lacking. ANGLE Project
ANGLE (Almost Native Graphics Layer Engine) is an open source project
[code.google.com] by Google. Its aim is to map OpenGL ES 2.0 API calls
to DirectX 9 API. A regularly updated version of it is part of qtbase
[qt.gitorious.org] .
To compile Qt with ANGLE you have to have a Direct X SDK
[msdn.microsoft.com] installed. Starting from Windows Kit 8, this is
included in the Windows SDK.
If ANGLE is used in your application, you should ship
d3dcompiler_XX.dll along with the Qt libraries. The version string of
the D3D shader compiler is pulled from the DirectX SDK header, so make
sure to get the same version that ANGLE was built with (e.g. _43 or
_46). This becomes especially important if you configure Qt with -angle-d3d11. Recommendations Use Desktop OpenGL if Your application uses OpenGL calls not part of OpenGL ES 2.0 Your application does not
use OpenGL at all (since ANGLE implies additional deployment
dependencies which are then not needed). Your application needs to run
on Windows XP. Although it is tempting to use ANGLE as a replacement
for missing graphics drivers on this platform, it does not fully work
and may lead to crashes, for example, when the security dialog is
opened.
Use ANGLE if You need OpenGL ES features, but not full OpenGL You have
a heterogeneous user base with different Windows versions & graphics
cards You do not want your user to have to install a recent graphics
card driver You want to use the video playback functionality of
QtMultimedia (see QTBUG-31800 [bugreports.qt-project.org] ) Your
application needs to run over Windows Remote Desktop Protocol (see
OpenGL and Remote Desktop [social.technet.microsoft.com])
Further Reading
http://qt-project.org/doc/qt-5.1/qtdoc/requirements-win.html
http://qt-project.org/doc/qt-5.1/qtopengl/qtopengl-index.html
http://blog.qt.digia.com/blog/2012/10/24/graphics-on-windows-from-a-different-angle/
http://blogs.msdn.com/b/chuckw/archive/2012/05/07/hlsl-fxc-and-d3dcompile.aspx
I know it is weird but I need to execute a Qt GUI application that supports X11 protocol on MS Windows platform.
It is obvious that if I build my Qt source code in Unix environment it automatically becomes an X11 application and this application can be run only on Unix Operating Systems, not MS Windows.
I tried to use MXE (MinGW cross environment) to compile my application in Unix for Windows, but it does not help for X11 issue. It creates an application for Windows but the application is not an XWindow application.
There is also a XPortMinGW project for minGW. But I do not know if it works for Qt applications.
Is there any way to build my Qt application with X11 support that can run in Windows OS?
I don't think that there's any need for cross-compilation. There are two problems:
Getting Xlib compiled for Windows. I don't know offhand of any maintained Xlib implementations that are ported to Windows. You will definitely need to find one, or make one. Hopefully Xlib depends only on a handful of posix APIs and they may be easy to translate to win32. Forget about Cygwin.
You may have luck porting Xlib yourself to Qt's network backend and making it cross-platform in the process, too. Xlib would simply use the core and network modules of Qt. No problem with that.
The good news here are that Qt 5 comes with a bundled Xlib implementation. It would be presumably much easier to get that to compile on Windows than some other implementation.
Configuring Qt to build using said Xlib on Windows. To do it right, you'll probably want to mess a bit with and rebuild the configure tool that comes with Qt, and add a makespec that will link with the Xlib.
This should be much easier to do with Qt 5.
It's not an entirely trivial thing to do, but should be possible. Give yourself a month and expect to get very intimate with some details of Qt's configuration and Xlib.
Notes About Cygwin
If your application is closed-source and distributed outside of your organization, you need to buy a commercial license in order to redistribute cygwin.dll. Otherwise, Cygwin is GPL and merely linking to cygwin.dll makes your application a derived work.
Cygwin becomes problematic when you mix posix- and non-posix code in the same application, especially if the non-posix code is a large framework like Qt. You can of course use the Posix platform code in Qt and make it all run on Cygwin, but that way you lose performance and expose yourself to shortcoming of Cygwin's emulation of POSIX APIs.
Using Cygwin for Xlib / windowing system but having Qt otherwise use Windows APIs may require a lot of tweaking for Qt code. So may using Qt with Xlib on Windows of course, but at least you don't have to debug/work around Cygwin's quirks.
If so, are there any platform specific code to be modified, or any other apparent issues observed?
QTouchEvent was added in Qt 4.6: http://doc.qt.nokia.com/latest/qtouchevent.html
There are some examples of what Qt have done:
http://www.youtube.com/watch?v=b749KvoX3w4
There are limitations in that the underlying windowing system needs to support this, such as Windows 7.
I have started using Python for web development recently, it's kinda cool;
I have seen programs that are developed in QT/C++, which is good enough in terms of esthetics;
I have just noticed the new PySide project (which brings LGPL Qt license to Python and it doesn't support Windows yet).
In view of the above, I see the possibility of using Python + PyQt/PySide to develop cross platform apps in the future :) but I have several doubts right now:
Can PyQty/PySide be used to develop really complex/modern UI? Can somebody give me some points to have a look at some nice-looking screenshots of apps that are developed in Python+QT?
What about the performance of using Python + QT for a desktop app?
Thanks in advance!
Can PyQty/PySide be used to develop really complex/modern UI?
Desktop applications come in all sorts of varieties -- some nicely laid out, some extremely customized with virtually no semblance to a standard application for that OS. The same can be done with Qt/PyQt/PySide. As Alex said, there should be no visible difference between an application written with PyQt/PySide versus one written with Qt in C++. Any program written with Qt4 (using bindings or not) will, by default, look like a standard modern application.
Of course, there are features of recent Windows releases (and likely some on Mac OS X) that aren't supported immediately and by default in Qt, but you can almost always write some custom platform specific code for those situations where said features are truly important.
Can somebody give me some points to have a look at some nice-looking screenshots of apps that are developed in Python+QT?
The best and most open source program that I know of and which is written with PyQt, is Eric -- a Python based IDE.
What about the performance of using Python + QT for a desktop app?
For most applications the performance difference between a C++ Qt application and a PyQt application are not noticible. But if you really need performance, you can write certain parts of the application in C++ and make bindings available in Python so you can integrate the two.
TortoiseHg was re-designed using Qt and PyQt for its 2.0 release.
Here is one of several posted screenshots:
There is no aesthetic difference between the look and feel of C++ based Qt, and the PyQt and PySide wrappers on top of it. I use basically no desktop GUI apps so I couldn't point you to any implemented with any of these language/toolkit combos, but if you like the former, you'll be hard put to distinguish it in any way from the latter.
A bit late but for the record, apps such as Skype, GoogleEarth or the recent versions of VLC (media player & more) used the Qt libs.