QML and Qt Quick

@jsulm
Yes

@Groundbounce
I have not look at the book. But do you understand that a "path" starting with qrc: means that it is an embedded Qt resource file, as per @SGaist above? You will not find that as an external file in your actual file system, rather you will have designed it to be embedded in your executable. Which I can only presume the book will have shown you.

@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.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.