QML and Qt Quick

Try Window.resize( width, height ); showFullScreen may not work sometimes. Check this out: https://doc.qt.io/qt-5/qwidget.html#showFullScreen

@KRHC hi and welcome to devnet, You need QApplication if you use anything that relies on the widgets module. Otherwise, there's no need for it and you would just bloat your deployment for no good reason.

@jsulm said in how to link with "so" files: put the lib next to the exe (in same folder) This works for Windows but not Linux. For Linux, you'd need to use chrpath or patchelf to set your application's RUNPATH (or RPATH) to $ORIGIN if you want it to search its folder for libraries.

@jeremy_k said in how to use QFile().flash?: Calling close() followed by flush(), or any file operation that expects an open file doesn't make sense. You're right of course I did not notice that there was a close() before flush(). @nishiokas this indeed makes no sense.

@ckielwein said in GridView reuse pool: Is there a simple way to implement a reuse pool myself? Leveraging the Component.completed and Component.destruction signals to reparent expensive delegate internals should work. It may take some effort to prevent bindings in pooled instances from wreaking havoc, but that seems to be a concern for the ListView and TableView implementations too.

@Mc6bullet said in Issue with fullscreen: I want to show those also Then this is not what "full-screen" is. What you want is simply a maximized window: https://doc.qt.io/qt-5/qwidget.html#showMaximized

I think what you want is to set the source model. proxyModel.setSourceModel(*instance of GatewayModel*); And then just declare it in main: engine.rootContext()->setContextProperty("ProxyModel", instance of ProxyModel);

qt 5.15.2 android 10 arm64 android 8.1 x86

@IntruderExcluder I see, thank you for the tip. It seems that I am able to just access the roles right now like the default 'display' without needing the 'model' keyword, but I guess once I modify the roles, I should probably add the 'model' keyword in. Your comment should also technically be part of the solution, but I can only mark 1 post as the answer, so I just want to note that here.

@J-Hilk It should be noted that "declarative-widgets" does not place QtWidgets within the QML rendering, it only allows declaring (pointing to properties) of the QtWidgets using QML.

it seems that it is important which file is used in the engine QQmlApplicationEngine engine; engine.load(QUrl(QStringLiteral("qrc:/login.qml"))); As long as i keep everything in this qml the behaviour is "normal". If I change to another ApplicationWindow with a loader I get the strange thinks. Maybe I have to change to a layout with only one ApplicationWindow

@Mc6bullet Ah, sorry did not realised you asked in QML forum! Maybe this can help: https://stackoverflow.com/questions/8970766/qml-main-window-position-on-start-screen-center/26424028

[image: bb00629f-0cb7-47dc-b984-36d1ee32f7fb.png]

@Evgeniy-Dushistov I had not noticed that previously, and there's no obvious mention of it in the documentation. Thanks! I see the same thing with this code: import QtQuick 2.15 import QtQuick.Window 2.15 Window { id: root property Rectangle myRect Component { id: myComponent Rectangle { color: "yellow" } } MouseArea { anchors.fill: parent onClicked: { if (loader.status == Loader.Null) { loader.sourceComponent = myComponent; myRect = loader.item; } else { loader.sourceComponent = null; } } } Loader { id: loader anchors.fill: parent } Text { anchors.centerIn: parent; text: "myRect: " + root.myRect } } My guess is that the properties that hold a QObject are tracked with a QPointer, but I'm not familiar enough with the implementation to find the answer quickly.

@jsulm : I got the answer after posting in mailing list, Thanks for your direction. Here is the answer for my query, Qt may spawn additional threads internally. ~100% of the time, they're invisible to the developer, and used just by Qt for its own purposes. In other words, the code you're going to write will run in the main thread and you'll never know about the other threads. Just ignore their existence. QtQuick has one special thread of you should aware of, which is its rendering thread. If you plan to do custom drawing, in C++, using QtQuick APIs, then the docs will tell you about this rendering thread and how to avoid shooting yourself in the foot. But if you just use QtQuick from QML, or use C++ drawing bits that aren't related to QtQuick (like QImage, then again everything will be ran in the main/GUI thread.

@poncho524 said in QList<*QObject> property thread safety: if one thread is updating a QList<*QObjects> and the qml thread is using this as a ListView model, how can thread safety be guarenteed? There's a multithreading list model example that covers updating a ListModel outside of the gui thread. The Qt containers are documented as thread-safe only if the container is read-only. Otherwise, mutual exclusion is necessary to protect accesses. QObject also isn't thread safe. If they are allocated in a worker thread, don't forget to QObject::moveToThread() before the gui thread has an opportunity for access. Once that is done, the worker thread can't safely access the object.

@ocgltd does your image show in a simple Image-Component ? Because Qt does not support all kinds of SVG formats only, IIRC; the "tiny" ones