Hello, I'm dynamically spawning hit objects in c++, which consequently doesn't come with any on-screen visuals for the user to look at. To fix this issue, I'm planning on setting up some qml code to add visuals to each object. That said, I do have a couple questions about efficiency here: Would it be better to connect each dynamically-produced c++ object to a qml file and control most of the functionality through the backend, or should I spawn a qml component for each dynamically-created c++ object and sync them up? If the first is true, the syntax to get everything up and running is unclear to me. How can I let qt know to have a qml object ready for each c++ object? I took a look at the documentation, and apparently, there's a way to spawn a component from c++'s end. I'm running this code in the object's constructor so the qml code will be set up on time and sync properly. QQmlEngine *engine = qmlEngine(this); QQmlComponent component(engine, QUrl::fromLocalFile("HitObject.qml")); hitObjectQml = qobject_cast<QQuickItem*>(component.create()); hitObjectQml->setParentItem(hitObjectQml); Could I safely set hitObjectQml's position properties through this method? I'm hoping to handle smooth and consistent movement from c++'s side via to deltatime handling. If it's actually more efficient to dynamically create qml components and hook them up to a c++ class, can I have some assistance in setting that up? Thanks in advance!

@DevWinDemon said in Qt5 is better than Qt6: Why they can't just create normal compiler that can create apps normally without problems. That is because the easiest way to conform with the LGPL is to use DLLs. What you want is static linking (which is a little harder to adhere to with the LGPL). But, what you probably really want is the paid version of Qt. @DevWinDemon said in Qt5 is better than Qt6: Why they can't just create normal compiler that can create apps normally without problems. On Windows, most libraries work like that. It is quite common to use DLLs. This always has a certain baggage attached to it. The most common way to solve this is to use an installer. I'm not sure where you got the idea that Qt should create a "normal compiler" because they never had a compiler in the first place.

Hi @Thomas-Prampart, and welcome! The requirements are the same as before: You need Qt Design Studio Enterprise to import a *.qtbridge file

@HarryGoddardTech said in Invalid metadata: I'm getting the following error when I run "Squish for Qt 9.0.0" Please clarify what you mean by this. For example, Do you get the error when launching the Squish IDE? or During the execution of the already existing test suite? It might be worth checking the "System Level" and/or "User Level" PATH environment variable to confirm no Qt related path is included.

I am a student interested in becoming Qt certified, but I’ve noticed that the certification exams are currently unavailable. I wanted to ask if there is an estimated timeline for when the Qt certification program will be open again

C# Tutorial, we will learn about .net C# and also learn Windows Form Basic & Console Application using C# (Sharp) like data types, and OOP concepts.

很容易找到啊， 没找到给我发消息.

Hi @RokeJulianLockhart, just some additional thoughts to consider... Kubuntu is an official "flavor" of Ubuntu. That is, its supported by Ubunutu, and has the same LTS and non-LTS releases Ubuntu has. KDE Neon is based-on an LTS Ubuntu, but is not supported by Ubuntu. It contains more recent KDE components, and is maintained (not sure about supported) by KDE devs. So there's definitely pro's and con's to both. But I'm sure both are good either way. I ask about Kubuntu explicitly because it's Qt-based, being the KDE Plasma variant, so I prefer it for verifying Qt bugs. While KDE is Qt-based, it actually uses Qt-derived libs, rather than Qt per se. So while it really doesn't matter, if you really like to use Qt on Ubuntu (as I do), then I can recommend Lubuntu, which is also an official Ubuntu flavour (supported by Ubuntu), but using the LXQt desktop by default instead. LXQt is a lightweight Qt-based desktop environment, so much more Qt-pure than KDE is (though again, it really doesn't matter). It's certainly not as feature rich as KDE, but then its without KDE's bloat too. LXQt suits my needs perfectly (by largely staying out of my way), but of course might not be right for you. Worth knowing about anyway. Cheers.