QML and Qt Quick

:-) Lots of stuff to study, that's exactly what I've been looking for, thank you!

This StackOverflow reply suggests a layout very similar to what I have so I guess I am not trying to do something unreasonable. Essentially, the question comes down to: how do I ensure that my QML files under test can be found when the test runs?

I confirm the same problem MenuBar with QT 5.12.7 QT Labs Platform Experimental 1.1 under linux CentOS 7 (+last updates). I tried to use unsuccessfully: QT+=widgets & QApplication & with/without QCoreApplication::setAttribute(Qt::AA_DontUseNativeMenuBar). But the qml control FileDialog perfect works as system FileDialog as widget FileDialog (Qt::AA_DontUseNativeDialogs). PS Under the windows ( qt 5.13 ) it works fine. PPS main.qml: import QtQuick 2.12 import QtQuick.Window 2.12 import QtQuick.Controls 2.12 import QtQuick.Layouts 1.12 import QtQuick.Dialogs 1.3 as OldDialogs import Qt.labs.platform 1.1 import Qt.labs.settings 1.1 import "qrc:/../3rdparty/controls" ApplicationWindow { visible: true width: 1024 height: 600 minimumWidth: 400 minimumHeight: 200 ... MenuBar { Menu { title: qsTr("&File") Menu { title: qsTr("&New") ... FileDialog { fileMode: FileDialog.OpenFile ... The solution: Do not use Qt labs anymore :-///

@JKSH , Thanks for the reply Line #13 produce error, i din't see it before. https://doc.qt.io/qt-5/qtqml-syntax-propertybinding.html , this link was useful. I wrote this code to understand the difference between visual parent and object parent. I know it makes no sense. But since i found an error, i thought to get it clarified. Thank You!

@G-P-Ranjan said in javascript decorators in QML: Does Qt-5.12.x or above - any version support decorators on its Javascript functions? Is it considered an ECMA-6 feature? Qt 5.12 supports ECMAScript 7. However, it looks like Decorators are still in the Proposal stage, not yet part of the standard: https://github.com/tc39/proposal-decorators

Also note, if you are instancing an object from a QQmlComponent you need to specify the context or it won't see any of the variables from the parent: QQuickItem* child = dynamic_cast<QQuickItem*>(m_delegate->create(m_delegate->creationContext())); //m_children.push_back(child); // not needed, implementation specific child->setParentItem(this); I also think this is the appropriate location to create a custom context for injecting node specific properties into the context. Anyway, now I am having fun!

x and y are in pixels. So you will get the first item for the amount of pixels of your first delegate's width. It is not recommended to access delegates from outside. ListView can create, delete, swap the delegate instances at any time and it will not warn you about it. Your reference might get deleted while you are processing it. As for better: there is itemAtIndex() but my warnings still apply.

@MikhailG in addition to @raven-worx response, could it be possible you try other non-Qt app via RDP? That way you might check the status of the overall RDP session, in particular the connection speed.

I think just take a step back and redesign that. Because as is it'd be a bad idea. It's a bad idea because you will have a self contained component but then somethine totally unrelated apart from the fact that you've now (if even possible) got references to an object that has no concept of it being relying on. That would be a maintenance nightmare should it all look like that. Being a javascript engine currently though - I probably don't even want to know if it might be made to work. I curse javascript, it's origins, everything. It's just so... yuck. Either way, I think the spirit of this post is: how you will essentially - abuse yourself. If you want: a single instance - just do that. to declare so when QML loads it it instantiates (it looks like you are) - just do that too. But what I think you want/ask now is: declare once, in another, completely unrelated component use the instance. It feels really dangerous. What happens when a.qml drops dbus or even changes the reference to suit itself, or the project drops a altogether? Now shit's really broke, now you've got strange shit happening in a as b fiddles with it's instance internals! At least, if I understand what you ask...

I have to say, that with all this effort to get treeview to behave it is not really doing what I want anyway. If you give a path to the QFileSystemModel and then hand this to the tree view it forces navigation of the entire path to get to the target directory: [image: 25954c43-0f16-4e4a-8467-3bf08e700db8.png] This is really annoying. I think with the problems I am having I may have to rewrite TreeView and hopefully not have to rewrite QFileSystemModel. I am just not sure where the path problem is yet. Argh!

I see: "qrc:/" is an URL scheme like http:/ or file:/ which is used when using QUrl. QFile on the other hand does no make use of schemes therefor the :/ which means: root of the "resources filesystem".

@bronstein87 Your welcome

@MikhailG I'm going to stick my neck and suggest there will not be any such facility.

Maybe you can use qsTranslate() instead of qsTr() to define the context ? At least that was useful for me since the value to translate was passed by another QML file translateStr = qsTr("TrContext", "hello")

As @daljit97 - I came here to say this too - do processing out of the GUI. Just for your own exposure - there is plenty of other kinds of networking examples too like: https://doc.qt.io/qt-5/qtnetwork-torrent-example.html More @ https://doc.qt.io/qt-5/qtnetwork-index.html https://doc.qt.io/qt-5/qudpsocket.html https://doc.qt.io/qt-5/qtcpsocket.html https://doc.qt.io/qt-5/qsslsocket.html https://doc.qt.io/qt-5/qsctpsocket.html etc Again, I'd highly encourage to disconnect anything not GUI into c++ and pass signals of only the data you care for on completion / event signals. It just keeps gui maintainable and cleanly separated from functionality.

@sierdzio thank you for sharing your experience. An important point for our development team is to allow the designers to write a part of the qml code, at least to basically create the interface as they want, or to be able to modify a part of the interface during the development cycle without having to resort to developers. I must clarify that they have the skills to achieve that. We also have the possibility to reload any modified qml file on runtime from inside our apps, so the modifications may be shown directly into the running application. So, what I'm searching for is a framework or IDE which would allow to write qml code in the most possible independent way. Until now the closest tools I found were Qt Creator and Qt Design Studio, but Qt Creator is problematic when the qml code links to custom c++ widgets or references (especially when the code is created with Visual Studio), whereas Qt Design Studio allows to create a pure qml interface, but needs to be converted before using it in a real c++ project. 2 questions interest me: Are there any other tools than the 2 mentioned above to generate qml content? How other development teams manage the change cycles between the design teams and the programming teams?

@DBoosalis You have to check with https://bugreports.qt.io/secure/Dashboard.jspa and eventually file a bug report. This forum is not monitored for eventual bug reports.