QML and Qt Quick

A QML singleton file is hardly more complicated and has the benefit of being typed and using a proper module import, making the tooling easy. // Globals.qml pragma singleton import QtQml QtObject { readonly property string defaultUrl: "https://www.qt.io" }

Please try a more recent Qt version. 5.15 is EOL. I can’t reproduce this on 6.5.

That depends on what you specify for your UX. If you don't want to have to use a submit button then mapping each textfield to a c++ property is the more direct way yes. Doing that on editingFinished is a good solution.

@SeeLook, is it accessible from outside QML?

Sounds correct yes.

This import does not import a file, but a directory, which is why the above error is always reported: no such directory I understand a little bit now. The use of qml is like the classes and objects of c++. What are defined in the qml file are types. When using them, they cannot be directly referenced by the type name (unless a singleton object is defined). Instead, an object instance should be created using the type defined in qml, and then this instance object should be referenced. For example: [image: 657e3e2e-02f6-4281-a2e6-b140b5aaa175.png] [image: 2b622949-0b55-46e7-82e9-4037d087037f.png] [image: 9f3149dd-971c-4580-a884-3aaa349f0e46.png]

Use client-side validation in QML (e.g., IntValidator, DoubleValidator) for immediate input checks. After that, call a C++ Q_INVOKABLE method to perform server-side validation (e.g., check for unique name/image in the database). Ensure the database check is asynchronous to avoid blocking the UI, and provide feedback if the check fails (e.g., show an error message if the name/image isn't unique). This ensures both local and database validation while maintaining a smooth user experience.

To address this problem, you can try improving the dynamic sizing logic of the dialog using a more flexible approach that leverages implicit sizes more naturally. Here is an updated version of the dialog component, with improved sizing logic to handle dynamic text wrapping without manually adjusting the size of the dialog: import QtQuick 2.9 import QtQuick.Controls 2.2 Dialog { id: dlg visible: true title: "My Dialog" property var msgText: "" // Initialize msgText to avoid undefined issues property var parentWindow width: Math.min(buttons.implicitWidth * 1.5, parentWindow ? parentWindow.width : 600) height: Math.min(msg.implicitHeight + footer.implicitHeight + 20, parentWindow ? parentWindow.height : 400) x: (parentWindow ? parentWindow.width : 600) / 2 - width / 2 y: (parentWindow ? parentWindow.height : 400) / 2 - height / 2 header: Label { text: dlg.title font.bold: true } Text { id: msg text: msgText || "No message provided." width: dlg.width - 40 // Padding for the dialog's width textFormat: Text.StyledText wrapMode: Text.WordWrap anchors.horizontalCenter: parent.horizontalCenter color: "black" } footer: Item { width: dlg.width height: buttons.implicitHeight Row { id: buttons anchors.horizontalCenter: parent.horizontalCenter padding: 5 spacing: 10 Button { text: "OK" onClicked: dlg.accept() } Button { text: "Cancel" onClicked: dlg.reject() } } } }

It has been resolved. It was caused by selecting a different version of Qt in the build configuration

Thanks guys, this was that.

Easy way - QChar has a constructor that takes unicode. QChar sdegree(0x00B0);

Seems to work with qsTranslate in qml and QT_TRANSLATE_NOOP in the vector (inspired by http://imaginativethinking.ca/how-the-heck-can-i-use-qstr-with-variables/). Thank you all.

The problem is that every unique value of grAnim causes a new texture to be generated and stored in the cache: https://bugreports.qt.io/browse/QTBUG-136553

The existing answers are correct, but to amend them: With qmlRegisterSingletonInstance, the same instance is shared by all engines (which can be somewhat problematic when there's more than one), whereas with qmlRegisterSingletonType, each engine will end up with its own instance. Please see also https://doc.qt.io/qt-6/qml-singleton.html , especially the sections on "Exposing an existing object as a singleton", "Imperative type registration" and "Guidelines for (not) using singletons".

Improperly explained problems lead to bad answers. I'm not sure I properly understand what you are asking so I probably won't answer it either and each time I read your question I understand a completely different thing of the previous read. I've read five times and I'm still unsure about what I should understand. If I'm understanding it right, you might be willing to instanciate an object outside a Loader, but be able to access it within it ? if yes then you need to use a binding. Item { id: rootItem SerialData { id: serialData } Loader { id: loader source: someCondition ? "page1.qml" : "page2.qml" } Binding { target: loader property: "serialData" // the property name as it will be available inside the loader WITHIN PARENTHESES value: data } } and inside your loader you can access your property classically via rootItem.serialData other option : you want to instantiate your SerialData component inside some component and make it accessible to it's parent. Then you can declare it as a property inside the component that instanciates it and thus make it available to the parent component. Doing this for data properties is fine, but injecting out an object is bad architecture. That's a very bad choice. It is much cleaner to create it in the main page and inject it into the subpages rather than creating it in a subpage and injecting it out to the main page and back to the siblings.

@JoeCFD Hi, Do you know of any sample code?

You're right, thanks. Running with paramter "-platform xcb" works. (Then, of course, it is no longer Wayland)