Mobile and Embedded

If you want something more fancy, there are links provided in the bug reports to help you do that.

@Gourmet Gerate don't forget to set this topic to solved, as I'm sure other people will search for an answer to something like this too :D

A rather late reply but I just saw this while trying to resolve this same problem myself. I tried several suggestions I found but the one that worked was to go into the Advanced Options section of raspi-config and pick the GL Driver (A8). In the new window pick G3 - "Full KMS". You will need to reboot after changing the setting, but that got rid of the warning message for me. Still mentions using the qt5ct plugin and I don't know if that's important or not because I'm trying to learn how to use styling (currently on QSlider) and just about nothing seems to work like it does on my Linux Mint development system. About the only thing I can configure on the handle is the background color. Things like height, width and border-radius seem to have no effect. I'm really hoping I'm doing something wrong rather than that there are issues with PyQt5 on the RPi.

There is a bug reported for this issue and you can find the workaround in the first comment: https://bugreports.qt.io/browse/QTCREATORBUG-24248

@J-Hilk I don't use an ApplicationWindow, just a simple Window. my onReleased code is there. it is not triggered by the swipe action to do an Android back event. the onClosing is working :) I guess I can implement a state machine to remember the previous view (either due to a change of source of my main Loader or the index of the active SwipeView) Cool, thanks ;)

So we have a patch to change the QMAKE_CFLAGS_OPTIMIZE and QMAKE_CFLAGS_OPTIMIZE_FULL flags based on the product we are building it for. I am passing in a value using 'device-option' to the configure script in qtbase. However, for some reason, that value is not getting passed to qtbase/mkspecs/common/gcc-base.conf

Hi One reason can be the touch setup -- Can you please explain a little more on this? Well since it only happens sometimes, i guess its not that. I have seen something like it when touch was setup for gestures and you kinda moved the finger when you "clicked" it would then start the gesture and sort of eat the click. Could also be a bug in Qt4.8 that the later fixed with Grabmouse -- Is there any defect ID that you remember? That will add more waitage for the understanding. Sorry nope. it was a duck. It was due to calling a message box that would run event loop and button would not redraw before after. One of the other thought that I have is, if this is really a UI issue or this is being a side effect due to any other -problems such as CPU load, Memory full, etc. Do you think it is possible? Yes that is really possible if the target is low powered board and it's low on say ram then the same task might suddenly take much longer and the button will appear down. Have you tested with a button that does nothing and see if that can get stuck?

@MrCrackPotBuilder Thanks a lot for your investigation. It probably saved me a week. Thanks!

Solved, in fact I don't know the exact reason. I just checked some static libs in my project and changed a little bit.

I found solution. My CmakeLists.txt contained: SET(CMAKE_CXX_FLAGS "<something>") QtCreator creates its own CMAKE_CXX_FLAGS, so we just need to change it to: SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS } <something>")

I couldn't fix it for hours ... I downgraded the version of QtCreator TO 4.10 and errors were shown... Solution here: https://forum.qt.io/topic/117303/qtcreator-doesn-t-find-standard-headers/3

I had the exact same problem today. Fixed it eventually by making the connection to QLowEnergyController::serviceDiscovered queued (Qt::QueuedConnection). I don't really understand why this helps, but apparently the QLowEnergyController cannot create a QLowEnergyService object in an unqueued callback from the serviceDiscovered event. Maybe the internal administration of QlowEnergyController is not completely done yet at the time of the event and creating a service object at that point results in an unknown error (error string is empty, so that also doesn't help). I looked at the code of the Low Energy Scanner example and there they also don't use a queued connection (although the Qt::autoconnection type can result in a queued connection). Looks like a sloppy implementation on QT side: code only works if called from a certain thread and error message is completely uninformative.

Thanks @J-Hilk. Did you consider that OEM shipped samsung keyboard can launch number keypad without combining ". and -" Launched from QT/QML [image: 1ee42f36-59b6-4634-8921-e61dc82a6d21.png] VS Launched from Android native app [image: 6fc07a82-9c3d-495b-8fe3-222dee4d74eb.png] SO i guess QT is launching number keypad with some setting. One more finding here is if any keyboard has such combined key, such issue could appear. Thanks for your suggestion, we thought of implementing the 1st suggestion and custom component which looks like [ ].[ ].[ ].[ ]. Second would be not very good solution as we would like to stick with Keyboard's provided number keypad rather than creating self.