QML and Qt Quick

@jsulm Thank you for your help:). I successfully resolved the issue, but I'm not sure if my approach follows standard practices. I noticed that the build directory for the QML module was correctly placed under /qml by default, but using QQmlApplicationEngine's loadFromModule or load methods attempted to search under the /bin directory. My solution was to build the QML module files into the /bin directory: OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin And based on the information you provided, I used “addImportPath”: engine.addImportPath(QDir::currentPath()); engine.load("qml/login.qml"); This successfully resolved the issue of not being able to locate "login.qml", but I'm uncertain whether this is a sustainable solution and if it aligns with proper practices."

@DesiVideoGamer hi, Your class does not: inherit from QObject include the Q_OBJECT macro Hence there's no reason for moc to be doing anything.

Hi all, Seems like all that above was cleared out with Qt 6. At least looking from Qt 6.9 point of view. QGuiApplication::palette() keeps system colors either for Android and Windows now (I'm not able to confirm that for MacOS). Which means either Windows accent color and Android (14+) accent color is QGuiApplication::palette() just out of the box. The same with light/dark stuff. All is inside. And this C++ QPalette is SystemPalette under QML. Still, If one want to mess up with QML Material accent color, just add something like below to the main *.qml file: import QtQuick.Controls.Material // ... SystemPalette { id: activePalette colorGroup: SystemPalette.Active } Material.accent: activePalette.highlight And similar applies to Mac style, I guess.

@kkoehne sorry for tagging you, but do you know anything about that?

@mr_broccoli the graphics view (QGraphicsView) can make use of a QOpenGLWidget as viewport in order to get acceleration but it's not the default. See here

This sounds like a bug and I think you should report it to https://bugreports.qt.io/

@JKSH True. Agree with you. Expectation was that after adding the library path it should work. This is where my confusion.

https://forum.qt.io/topic/158541/windows-qt_add_qml_module-failed-to-load-the-plugin This may help

onStatusChanged has been removed in Qt 6. The software is packaged with an outdated version of Qt, while the user environment obviously provides a recent version. You need to port the app to Qt 6...

Partial solution which I found is to register this enum C++ class as creatable. Then in point where I need value names - is to call is JS section var obj = Qt.createQmlObject('import InfModule1.0; BackgroundType {}', parent); obj.names();

✅ Solution: Force layout recalculation after width changes To ensure layout syncs correctly, you need to explicitly trigger layout updates when the TableView or HorizontalHeaderView resizes. Fix: Add onWidthChanged: tableView.forceLayout() in both the TableView and the HorizontalHeaderView. 🔧 Updated code: TableView { id: tableView columnWidthProvider: function (column) { // Your width logic } onWidthChanged: tableView.forceLayout() } HorizontalHeaderView { id: header syncView: tableView onWidthChanged: tableView.forceLayout() } ✅ Even in HorizontalHeaderView, you call **tableView.forceLayout()**, not header.forceLayout(). 🧠 Why this works columnWidthProvider often runs before tableView.width is fully initialized or updated. forceLayout() triggers Qt to re-run layout and width calculations with correct sizing. syncView can now properly sync header and table widths based on the final layout pass. ✅ Result Now the header and table stay in perfect sync, even when: Resizing the window Stretching a specific column to take remaining space Changing content dynamically

Hi, Which version of Qt are you using ? On which OS ? I tested your code on macOS with 6.7.2 and it's working properly.

Same thing happens for me with Qt 6.9.2 on Windows Enterprise 10.0.26100. Both Qt.WindowModal and Qt.ApplicationModal are ignored. The Dialog from QtQuick.Controls with modal: true works as expected

@JKSH said in How to expose a normal function to QML?: Do you need to expose every single C function directly to your GUI? Perhaps you could design your wrapper class as an abstraction layer that exposes fewer but higher-level methods to QML, while these higher-level functions each call multiple lower-level C functions. You are absolutely right that not all functions need to be exposed to the GUI layer. However, there are still a significant number of functions that do need to be invoked directly from the GUI. For that reason, I believe your proposed solution of creating a controller or wrapper unit with automated C++ generation is indeed the best approach. That said, I’ll continue researching to see if there are any alternative technologies that might be a better fit for my situation.

Hi @JKSH ,It works for me. I disabled the pipeline cache by adding: QCoreApplication::setAttribute(Qt::AA_DisableShaderDiskCache); to main.cpp.

@Ronel_qtmaster Yes currently we are trying to use gpu and reduce the cpu load Below is the gstreamer pipeline i'm trying by using d3d11 QString( "rtspsrc location=%1 latency=0 protocols=tcp name=src " "src. ! rtph264depay ! h264parse ! tee name=t " "t. ! queue ! d3d11h264dec ! d3d11convert ! d3d11download " "! video/x-raw,format=RGB " "! appsink name=appsink emit-signals=true sync=false max-buffers=2 drop=true" ) and we are encoding and decoding to jpeg using turbojpeg library. Do you have any suggestions on using gpu or gstreamer pipeline We are also thinking of trying to send the h264 encoded data and stream that also.