@SGaist said in Qt and next Apple generation: You are 14 years late, Apple has ditched PowerPC for Intel in 2006. I mentioned the previous technology to describe the current Apple architecture, please forgive me. I wrote this question just before going to weekend, and I was quite tired. What I mention above is described in the following article: https://www.apple.com/newsroom/2020/06/apple-announces-mac-transition-to-apple-silicon/ I also corrected my post, thank you very much

Hi In most cases, there is nothing to change as Qt force is exactly to hide the platform details from you. You will have to use Qt functions for paths and special folders https://doc.qt.io/qt-5/qstandardpaths.html and be a bit careful if you construct filenames etc but else normally it will just work. Bluetooth might be another story as the support pr platform differs https://doc.qt.io/qt-5/qtbluetooth-index.html Also, Windows 10 had something some oddities wanting you to manually pair devices but on Linux you could auto pair/discover. I'm not sure the current status and it might just work. Nice day to you too :)

Hi, Check the QWidget::winId.

Hello and thank you for your quick reply. I tested this and unfortunalety this did not solve the problem. It is an interesting idea though. Setting the stayAtBottom hint is something we actually tried already. This leads to the mainwindow staying even further in the back than the undocked widget. So the rule child-not-infront-of-parent stays active for that case. So what i did try now was setting the stayOnTop hint whenever the mainwindow gets activated and removing it whenever it gets deactivated. this actually enables the child to be put behind its parent! In order to make this (partly) work i had to install an event filter for all undocked widgets because the windowActivate event is relayed from the dockwidget to the mainwindow apparently. So without the filter, everytime a user clicks on the undocked widget, the mainwindow would pop up back again over the child that should be in the foreground. So far, so good. All of this breaks however when trying to remove the stayOnTop flag from the mainwindow. The removal needs to happen everytime the focus of the mainwindow is lost. So i remove the WindowStayOnTopHint and afterwards have to call show() because windows disappear when changing window flags. The problem is that show() then again triggers the WindowActivate event, re-enabling the stayontop hint. This can be filtered but when i do this i end up with a situation where - for some reason - i need to click an undocked widget twice, once to put it to the foreground and a second time to actually activate the widget window. I am sure that this is a problem in my code and/or can be worked around but this solution starts to be getting dirtier and more hacky. So before diving further down that rabbit hole i would like to double check if there is a more straight forward solution the the actual problem. I also the fear side effects of setting the mainwindow to stay on top, especially if there is a thrid party application window (file explorer or whatever) involved that the user would expect to be "in between" my application windows (a user clicks on myMainwindow, file explorer, myUndockedWidget in that order type-of-situation). Thanks for reading all of this

Well, it's not something that's provided by Qt out of the box, so you'll have to check the platforms you want to support for how they provide that information. You could even consider contributing that to Qt to improve it for everybody. You might also open a feature request on the bug report system for that.

@CybeX 1:I saw on google that someone else had this error with gcc 4.8. Upgrading solved it. Not saying it will for you. But was the only errors i could find in your log. 2: Sorry I don't know how to solve this. People are compiling for the PI but I never got around to try one so the details of getting it to work is also unknown to me. Update: I have a good eye to https://www.ics.com/blog/configuring-qt-creator-raspberry-pi but no board so didnt try yet.

I can only second what @ambershark says. Using a virtual machine is far less pain than what you are trying.

Actually, I have now seen the .mov files played by QML's MediaPlayer on Windows. I'm making things slightly difficult for myself by not having a Windows machine in the house, so this has all been on an AWS EC2 instance; that gives you a Server2012R2 session... but that seems to have no media player support at all until you enable "Windows Desktop Experience". I also installed a "K-Lite Codec Pack", but since I'd installed that before I enabled the "desktop experience" stuff, I'm not sure if it was needed or not (will try and remove the codec pack at some point, if it's uninstallable; strongly suspect it is needed though). Anyway, that's the existence proof the .mov files can work I was looking for. Thanks for the other suggestions... I'm not too keen on turning to other tools like VLC or ffmpeg if I can possibly avoid it. Stock Qt has so far served me remarkably well as a one-stop shop for multiplatform applications and I'm very reluctant to have to bring in something else too. Transcoding my video content to something that worked everywhere would have been a more attractive solution if needed.

@sneubert Well, that's what I did not want to hear at all :) , but thanks anyway.

You're welcome ! Don't hesitate to ask them in separated threads (don't forget to search the forum though, there are already a lot of questions related to the RPi) :) If you're not lost anymore, please mark the thread as solved using the "Topic Tool" button so that other forum uses may know a solution has been found :)

different platform's require different Flow control. it is not true

Core i5 is for sure x86_64 and it can execute i386 binaries as well. Because x86_64 was invented by AMD and later implemented by Intel as well it is often called AMD x86_64.

http://api.kde.org/frameworks-api/frameworks5-apidocs/solid/html/index.html

@sierdzio said: Thanks a lot for the clarification.

@Asha Same problem.

You can put the name of mkspec you are used for the given platform. I think for Raspberry it's something like linux-rasp-pi-g++. Open the mkspecs/devices folder in your Qt installation and check it out or open the Kits propertties page in Qt Creator and see which mkspec your kits are using.

(But who knows what will happen when Windows 10 will be released..)