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.
Related
I can't find a definitive answer to this question: What is the actual, real, native, no-wrapper gui toolkit of Ubuntu?
I may fundamentally misunderstand something about the way that it works in linux, but I know that in Windows, for example, there are the low-level C APIs that comprise Windows's native windowing tooklit, and then various wrappers (such as that C++ library I can't remember the name of at the moment). But the actual native API is the C one.
On linux, there is no native gui; it's just a kernel. But in Ubuntu there's X11, GTK, Qt, and others, and I don't know what the REAL native toolkit is. I know that at least for Ubuntu Touch Canonical is moving to Qt as the native toolkit, but even in that case, will Qt be the REAL native toolkit, or is it just going to be a wrapper around X11, Mir, or something else?
Linux distros don't have a "native toolkit". Qt and GTK call the XLib, but the switch to Wayland is in progress, and Mir looks like a terrible idea for me. Anyway, the real low-level thing is: XLib, Wayland, or Mir. And the GUI toolkits, GTK, Qt are above these, and transparently use the right backend. Other toolkits like wxWidgets are on top of the "native toolkit" of the platform. For Linux, they chose GTK.
Ubuntu is moving to Qt, but was previously GTK, so you can't predict what it will be in the future. But the integration of your app depends on what your user runs as a desktop environment, so Qt or GTK are the best options. Qt is better for Windows portability, though.
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.
I have to port the application which is using the Qt3 library to a new embedded OS.
If the OS is not yet selected but it is known that it is not Linux/Windows, what is the general way of porting procedure? I mean what files should be changed and what are independed and can be left as is?
If it's not Linux or Windows you could be pretty stuck out the door. Qt is highly dependent on libraries being available for it to be able to build. This is not a no however, it has been ported to Symbian which is obviously not Linux or Windows. The big thing on that though is that it was ported by Nokia, who had amount of time and amount of developers, where those X's are reasonably big numbers.
Start by getting the Qt everywhere source code, work out what bits you're going to need and which bits you won't. If the platform has gcc/g++/another reasonably well understood C++ compiler you're in luck and you should be able to build the bits as needed. Qt does depend on standard libraries throughout so make sure they're also available in some form for the platform, and it does use some non-standard ones for some components so you'll need to know which aspects of Qt you're working on. You should be able to get some sort of toolchain from there.
I'd stick to platforms that Qt supports though, if you go off the beaten track you're looking into increasing your dev times and having very little useful support.
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 will make a desktop application. I searched on web which one is better. Can someone say positive and negative sides of these components.
I can add some information about QT:
QT is a well designed, portable library that covers nearly everything you'll need for a desktop application. QT covers GUI, networking, SQL, Graphics and more.
Pros:
very extensive library
high performance
portable
Cons:
It's C++
special preprocessor / make tool needed.
Setting up a QT compile environment is a little bit more difficult than setting up a C++ compile environment. C++ is - especially if you are not used to it - very difficult and the learning curve is steep. QT helps alot with appropriate helper classes (QPointer, ...) and library magic (QObjects freeing children, ...) in the background. There are bindings to other languages as well. Just to mention a few - Jambi is a binding for Java and there's a binding for python as well.
For your decision consider the following things
which programming language do you know best
which libray reduces your amout of work for this application the most
how much performance do you REALLY need. C++ code can be very fast, but there's no reason to work with manual memory management and pointers if you don't need the performance.
which library offers you the look and feel you want to have for your desktop application
If you need portability: Do you want to "compile once run everywhere" (Java) or do you want to "run your app everywhere once you compiled it for this plattform" (QT)
Here's the link to QT-Jambi Wiki: http://qt.gitorious.org/qt-jambi/pages/Home. According to Nokia: "Qt Jambi is the Qt GUI toolkit for Java developers"
Qt is the best cross platform GUI framework at the moment. It renders the widgets with a native look on each platform and it has a very easy to use API.
Using Qt doesn't mean that you have to use C++. You can program Qt in Java (Qt Jambi) or Python (PyQt) for instance.