QML and Qt Quick

@Praveen-Illa said in Facing an issue with Listview in Repeater: Hi Team, I am trying to control the visibility of the listview control on every button click for respective data model. But, I am getting below errors at "visible: buttonRepeater.model.expanded" Unable to assign [undefined] to bool Edited to emphasize the problem: Repeater { id: buttonRepeater model: groupModel delegate: Column { ListView { visible: buttonRepeater.model.expanded } } } buttonRepeater.model.expanded is attempting to access a property called expanded in buttonRepeater's model, not a role called expanded within a row of the model. Printing the values of buttonRepeater and buttonRepeater.model should make this clear.

Looks like it's QTBUG-133587. I also have .js files in QML_FILES.

@jeremy_k Thank you for your input. It seems I have to rethink the concept.

Hi, Are you looking for something like the Vulkan under QML example ?

You go the answer on this thread, correct ?

Okay so it seems that the problem is the compiler not being the same in Qt Creator than in Qt Design Studio. My Qt Creator kit on Windows is using MinGW but it's not compatible with whatever Qt Design Studio is using. Does someone know how to proceed?

@RokeJulianLockhart, per bugzilla.redhat.com/show_bug.cgi?id=2345428#c1: The real binary is installed into /usr/lib64/qt6/bin/qml, and symlinked to /usr/bin as qml-qt6 to not conflict with the Qt5 version.

@UnknownCollegeCoder said in Enabling arrow-key-navigation with QtVirtualKeyboard on Qt 5.15.1: Would you happen to know how I get this configuration to my current project? You don't! Again: this instruction is to BUILD Qt virtualkeyboard itself, not your project! After calling configure you call make and then "make install" (just like @Joseph-Keene shown already).

@RokeJulianLockhart don't be so harsh to your younger self. People make mistakes. You have to learn from them and grow past them :-)

QtQuick used to require a GPU to be present. But now a software renderer which has limitations. @SGaist, thanks for that. Never would have found that article in a million years. However, I found a comment which appears to summarise both its current state and why I asked this succinctly, if correct: Yes QtQuick is much much faster in rendering high resolution complex scenes due to leveraging the gpu through the use of QRHI. Its the awesome rendering abstraction Qt made so it will call Dx11 Dx12 Vulkan Metal Opengl depending on the platform you compile for. This ensures you use the best graphics api for the platform as Opengl drivers (from most gpu vendors)on windows sucks compared to DirectX, so much so google even developed ANGLE. But I hear you say the word ‘responsiveness’ and this is something were a very nasty truth comes to light about QtQuick. By default Qt uses VSync and a swapChain interval of 2 or 3 frames (you can configure this) to throttle the rendering so we are not rendering 7000fps for a screen that can only display 120 per second. This adds latency which is noticable to the user. Likewise, since I'm asking this in a KDE context, reddit.com/r/kde/comments/81dfdc/comment/dv37xdr is of use: Today we need to compare QWidget and QtQuick. QWidget is rendered with what raster used to be, so no. QtQuick is by default rendered with OpenGL, so yes. Though, I presume they mean QtWidgets in the stead of QWidget.

post/770024 The problem is inconsistency between the styles utilised by QtWidgets and QtQuick. It should be solved by Union. This is a user forum. You want to check the bug report system to discuss that matter. Thanks, @SGaist. I'd hoped back then that someone would link me to an existent BR for the problem, since I wasn't familiar enough with Qt back then to ascertain whether any of the reports that matched by queries at Jira were relevant.

Thanks for the help, Kai, your way got rid of the grouped property error [image: 7f603bcd-54bc-4ab1-8b39-1fbeef4531e0.png]

Yeah that's all working now I was receiving some errors W/default : qrc:/Main.qml:10:1: static plugin for module "URI " with name "URIPlugin" cannot be loaded: Namespace 'URI' has already been used for type registration. GlobalContextModule/pages/SignUp.qml:204 RolesList is not a type Solution to this I believe was to Make sure I hadn't repeated the import statement for our URI from the Parent cmakelists.txt. Where URI refers to URI of our target that we provided to target_include_directories. And our URI is declared in qt_add_qml_module Move the RolesList{} QML element from page in child module to Main.qml where our import statement was. Even though Main.qml loads this page in and in effect, should provide it with what it wants, it didn't for me in practice. Before we used QML_ELEMENT I had an import statement just for RolesList{} in page of child module but now that thing is in our Import URI in Main.qml. If that doesn't make any sense, basically all I'm saying is don't assume classes put inside of main module via QML_ELEMENT and CmakeLIsts.txt get passed down to child modules included into this main module

For anybody that cares, I ended up creating the floating icon on top of each gateIcon as it is created: GateIcon.qml: Component.onCompleted:{ floatingGateIcon.fromPalette = fromPalette floatingGateIcon.gateType = gateType floatingGateIcon.parentIcon = gateIcon floatingGateIcon.source = iconSource console.log(gateIcon.x,gateIcon.y) floatingGateIcon.createFloatingIcon(gateIcon.x,gateIcon.y); } then set propagateComposedEvents: true in the gateIcon mouse area.

Hi and welcome to devnet, The forum is not the best place to discuss these issues as it's mainly a user forum. You might want to check the bug report system to see if there's already something that matches your issues. If not, you could consider opening feature requests regarding the points you are mentioning.

Hi, I think GammaRay might be useful to find that kind of things.