Qt - Reddit

and ported them over. I would continue to use the Qt5 version in my dental clinic such that if there is a major bug that needs to be fixed, I can fix it that the Qt5 repo. Yes, I could have just made a separate branch instead; it but since I was switching to cmake as well, all the file locations would be changed as well and it would have been too complicated to move files around each time.

So pretty good plan, right? Well, mistakes were made (which is why I am writing this).

First mistake is using a lot of “raw” strings. When I made the decision to go with Kirigami and KDE, the standard build flags include `QT_NO_CAST_FROM_ASCII`. This means `QString s = “hello”;` is no longer valid. You have to use `QString s = QStringLiteral(“hello”);`. Sadly, a lot of code not only used a lot of raw stings, but QVariantMap was used rather extensively because it maps to QML’s Javascript class types and I exploited that to share data between C++ and QML and of course I did a lot of `object[“attribute”] = value;` in my code; which had to be switched to `object[QStringLiteral(“attribute”]) = value;`. Now, could I have done something to flag to allow to cast strings from ASCII? Probably. I was more concerned that making it a KDE App it may make it difficult in the long run to have flags specific to my app for Craft to build it. There is also an unfortunate issue that if you were to use the standard KDE build flags; you would have to switch over to macros like `Q_SLOT` instead of `slots:` and `Q_EMIT` instead of `emit`. I’m just hoping this will be better in the long run.

Second mistake was using QML’s “Settings” type rather extensively. When it was released in Qt 5, it was technically a “lab” component which means it was still in an experimental stage. At the time, I thought it just meant small changes would be made. For Qt 6, they removed the `fileName` attribute and replaced it with the `location` attribute. However, it requires the protocol for the file location. For example, if you were using a fileName attribute, you had `/home/example/test.ini`, but now you have to make `file:///home/example/test.ini`. Not a huge problem but if you miss any of the replacements (since I set some of the attributes via code, not just declarations), you get a realtime error, not compile time. Therefore a fair amount of testing is needed just to make sure nothing was missed.

Third mistake was relying too much on X11 positioning. When using Windows / macOS, X11 in a multi-monitor setup, you have pretty much a giant “virtual” screen and setting the x or y position would allow you to set which screen the window would show up. For example, if you had 3 monitors, all of them 1920x1080, stacked vertically. You can make a window show up at the middle screen by setting the y position to be 1080 or the bottom screen by setting y to be 2160. Guess what you can’t do Wayland? Set the position of the window (at least, not as of right now). To make matters worse, setting the screen via QML is still broken. There is a crazy workaround but you can only fullscreen on a target screen. Eventually, I have to setup which screen / monitor is which location (patient side, wall, ceiling) for each operatory and then rely that configuration to know which screen it to full screen that video.

Sorry again for the big wall of text but believe it or not, there were even more things I could have added to this already long writeup.

https://redd.it/1sealvm
@qt_reddit

From the QtFramework community on Reddit: My (self-inflected) painful journey from Qt 5 to Qt 6

Explore this post and more from the QtFramework community

3 views20:32