Qt5 porting tips/findings
-
After successfully compiling Qt5 with VS2010 (both x86 and x64) from git (didn't try webkit yet). I've ported our application to Qt5 this morning. Considering the size of the app things went fairly smooth. Big thumbs up to the developers!!
A few things I ran into that I did not see documented anywhere.
QDesktopServices::storageLocation has been moved to QStandardPaths::writableLocation
QTcpServer::incomingConnection(int handle) has been changed to QTcpServer::incomingConnection(qintptr handle)
this 2nd one is sneaky as it compiles properly but no connections appear to arrive since the compiler doesn't consider int and qintptr the same.
You can't pass a sequential QIODevice (like the QNetworkReply) to QImage.load it keeps spitting out warnings on the console. Copy your data to a QByteArray first then do QImage::loadFromData
QUrl::addQueryItem is gone use QUrlQuery
We do some interfacing with low level Windows function so we need to include windows.h on occasion. This conflicts with QDateTime.h something about std::numeric_limits<qint64>::min(); Either way easily fixed by moving the windows.h include below the Qt includes.
QFrame has a white background now instead of the default windows background color..
We're now testing the binary and will post here if we find any more differences.
-
Thanks for your job. I hope it will help people from devnet.
-
Thank you!.
When porting one of my projects to Qt5, I wondered why the tcp server had stopeed working. Your tip was exactly what I was looking for, would probably have spent a lot of time trying to figure this out. This is a nasty change for sure
-
You're most welcome. That little change cost us a lot of time, glad we were able to avoid others from suffering too much :)
-
Hi altera_2011, thank you for sharing your findings. I'd like to incorporate them into the official Qt documentation -- would that be ok with you?
-
Great thread!
I can report some undocumented changes, too:
- PostScript support (e.g. saving a QPainter-drawn graphic to .ps file) was completely removed, even if the documentation says otherwise. (See "this thread":http://qt-project.org/forums/viewthread/24857/)
- Whoever switched from QPointer to QWeakPointer for smart QObject tracking in Qt4.6 now must switch back, because this functionality was removed again from QWeakPointer and QPointer was undeprecated. Note that just using QPointer doesn't solve the issue if planning to be compatible with both Qt4 and Qt5, because "QPointer" has different functionality/performance in both versions. (See "this thread":http://qt-project.org/forums/viewthread/27510/)
- QPixmap::grabWindow was removed. Instead, one could try the QScreen::grabWindow function, although it's not a static one. I haven't found a way to find the QScreen instance the application you want to take a snapshot of is on, so I've settled with QGuiApplication::primaryScreen()->grabWindow for now.
- QApplication::setGraphicsSystem was removed without replacement. So now it's not possible to set the graphics system to raster or opengl when the native one doesn't properly work or has bad performance. Probably to encourage switching to QML.
- QTest::qWaitForWindowShown was removed. Functionality is replaced by qWaitForWindowExposed and/or qWaitForWindowActive
Hope this helps.
// Edit 09.05.13: added QTest::qWaitForWindowShown -
@JKSH Of course! Go ahead.
-
I found another previously-undocumented change:
- QPen now has a default width of 1 instead of 0, so it is no longer cosmetic by default.
Anyway, most of the changes listed in this thread have are now in the official documentation. Thanks for sharing them here, altera_2011 and DerManu. See https://codereview.qt-project.org/56853
The patch has been accepted, and the documentation should appear in http://doc-snapshot.qt-project.org/qt5-stable/qtdoc/sourcebreaks.html soon.
Some notes:
- The changes to QTcpServer, QPointer and PostScript support were documented before my patch -- you can already read them in the snapshot
- Did QImage::load() work with sequential devices in Qt 4? If it did, then it's a regression bug, not a porting issue (please report to http://bugreports.qt-project.org/ )
- The conflict with windows.h is a library conflict, not a porting issue (might still be worth reporting, to see if we can implement an easy workaround in Qt)
- I could not reproduce the QFrame change -- I created a blank QFrame in Windows 8 with Qt 5.1 beta 1, and it was grey, not white
-
"QTcpServer::incomingConnection(qintptr handle)"
You just made my night, spent an hour looking wondering if I was insane :)
-
Another good one is QString::toASCI() has been depreciated, use QString::toLatin1()
-
Yep. that change is incredibly sneaky since it doesn't throw any error. Glad it saved you some time
-
Hi altera_2011.
I'm going to port my Qt 4 application to Qt 5. I have a big Visual Studio (2008) solution with a lot of projects because I have a lot of qt plugins.
My doubt is about the Visual Studio project (and not about the application source code).
I know that with Qt 5 some modules have changed, so I would like to know what's the best procedure to port the Visual Studio project.
I don't know if I can use my old project and change the project settings, or if I must create a new project...Thanks
-
puffosauro, I wish I had good advice for you but we use qmake and QtCreator instead of the VS2010 IDE. So in that respect the change to Qt 5 was a non-event as qmake took care of the changes.
How did you create the visual studio projects?
-
I have used the Visual Studio Addin to create the VS projects and also to add Qt classes etc... so I don't have a .pro file.
-
I'm sorry I'm not familiar with the VS addin. Maybe someone else can give some suggestions.
-
[quote author="puffosauro" date="1389276361"]I have used the Visual Studio Addin to create the VS projects and also to add Qt classes etc... so I don't have a .pro file.
[/quote]You can export the project to .pro file from vsaddin. This is part of the Qt menu in msvc. I have done my migration from msvc to Qt creator that way.
-
[quote author="JKSH" date="1369361247"]I found another previously-undocumented change:
- QPen now has a default width of 1 instead of 0, so it is no longer cosmetic by default.[/quote]
Ouch
-
[quote author="koahnig" date="1389278461"]
You can export the project to .pro file from vsaddin. This is part of the Qt menu in msvc. I have done my migration from msvc to Qt creator that way. [/quote]Thanks. But I continue to use Visual Studio with the addin.
I have seen that it is easier than I thought, it's almost "automatic", I have only to add the new modules using the addin and I have to change the names of the libraries in the project settings (eg QtCore4.lib -> Qt5Core.lib)
....
[quote author="JKSH" date="1369361247"]
- QPen now has a default width of 1 instead of 0, so it is no longer cosmetic by default.
[/quote]
mamma mia!!!!!! :(
- QPen now has a default width of 1 instead of 0, so it is no longer cosmetic by default.
-
ERROR: 'class QApplication' has no member named 'argc'
FIX for QApplication::argc():
@
s_argc = app->arguments().size();
@FIX for QApplication::argv():
@
s_argv = new char*[s_argc + 1];
//
for (int i = 0; i < s_argc; i++) {
// current arg
std::string arg =
app->arguments().at(i).toStdString();
// copy arg to char** structure
s_argv[i] = new char[strlen(arg.c_str()) + 1];
memcpy(s_argv[i], arg.c_str(),
strlen(arg.c_str()) + 1); // +1 for '\0'
}
s_argv[s_argc] = ((char)NULL);
@My two cents :-)
-
ERROR: 'class QApplication' has no member named 'argc'
FIX for QApplication::argc():
@
s_argc = app->arguments().size();
@FIX for QApplication::argv():
@
s_argv = new char*[s_argc + 1];
//
for (int i = 0; i < s_argc; i++) {
// current arg
std::string arg =
app->arguments().at(i).toStdString();
// copy arg to char** structure
s_argv[i] = new char[strlen(arg.c_str()) + 1];
memcpy(s_argv[i], arg.c_str(),
strlen(arg.c_str()) + 1); // +1 for '\0'
}
s_argv[s_argc] = ((char)NULL);
@My two cents :-)