I want to start learning Qt for developing GUI's, and I'm trying to decide between the old Qt (not QtQuick1) and QtQuick2. I was hoping to use QtQuick2, but I'm confused about the opengl issues with Windows XP. My question is, will it be possible in Qt 5.4 to deploy a QtQuick2 GUI to Windows XP, without requiring the user to update any drivers? If not, are there any plans to make that possible in a future version of QtQuick?
edit: I know that Windows XP is really really old, but a lot of my potential customers are still using it.
On WinXP, prefer the ANGLE build of Qt5, which uses OpenGL ES over Direct3d instead of OpenGL. If you have customers using WinXP, then it's more than likely that they have never updated their drivers, which will cause problems for QtQuick.
I am sure you can not expect any improvements for Windows XP. DO NOT use XP anymore. Generally Qt5 has only very restricted XP compatibility (http://qt-project.org/doc/qt-5/supported-platforms.html).
If you want to start learning Qt you should use the newest Qt but you should drop Windows XP.
Related
I am considering to learn Ada. I found several resources online, and Programming in Ada 2012 by Barnes is on its way to here, so that should get me started.
The target machines for the future Ada programs are Intel 64 bit, and the target OSes are Win 8.1 and Win 10.
However, I was not able to find an example on how to interact with the Windows API in order to draw and manipulate Windows. Could someone please direct me to a source, so that I can have a look at how such code would look like?
Also, all I've read so far indicates, that Ada compiles only 32 bit executables for Windows. Is it correct that I can not generate true 64 bit Windows programs?
The recent GNAT community release does target 64bit. An alternative is TDM-GCC which has provided a GNAT release targeting 64bit for a while.
There is Win32Ada which is a binding to the Windows API. However, I don't think it has been updated with new APIs of Windows 8.1 or Windows 10. However, you can always import functions from the Windows API into Ada yourself.
There is GtkAda which allows you to use GTK to create GUIs. However, these are not „native“ Windows GUIs.
I'm just wondering, if the native app development support is now introduced to Windows phone 8, does this mean that we can -technically- develop Qt-based app and benefit from the QML technology?
There is a lengthy technical report on the feasibility of supporting Qt on Windows 8 here:
http://qt-project.org/wiki/Qt-5-on-Windows-8-and-Metro-UI
From the conclusions it sounds quite feasible.
A bit of an update to this old question, links:
Building Qt 5 for Windows 8 Modern UI (Windows Store Apps & Windows Phone 8)
Building and deploying your WinRT apps (Tech Preview 1)
Qt5 documentation snapshot: WinRT
So to answer the question: Yes, it's indeed technically possible. Still (start of 2014) in early stages of development, so everything does not work, project set up is clumsy etc, but looks pretty promising. No idea about when official out-of-the-box support might come to Qt 5 SDK, but Qt is open source, so you can start playing with it already.
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.
Allow phonetic typing
I have an application that works perfectly on all versions of Windows that are 32 bit. In the application to use the Dev Express v8.3 controls. When I try to start the application on x64 win 7 shooting in the old and see that there is a problem with reading a common-dll containing refernce to devexpress.- Bad image exception. Is there any idea of how effectively they can solve the problem?
You should really ask DevXpress if that old version of their library fully supports x64 machines or not.
In general pure .Net managed code does work well on all supported CPU architectures as IL is compiled by the jit compiler at runtime.
Your bad image f. error is surely related to cpu architecture issues but are you 100% sure is from one of the devxpress files?
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.