In porting to Qt 6 TreeView I am finding it tricky to reimplement some behaviour that I had in Qt 5. It seems that the API for programmatically setting nodes collapsed or expanded is now based on the visible rows. In Qt 5 it was based on model index. One might wonder why I am interested in expanding nodes that can't be seen. The reason is that various behaviours are specified such that certain nodes should be default expanded or contracted when first added to the tree. Some of these "expanded" nodes are children of nodes that initially default to contracted - in other words, they are expanded but this won't be seen until their parent is expanded. Note that the tree view itself cares about the expansion status of nodes that can't currently be seen. If a node is expanded and its parent is then collapsed and re-expanded, the child will remain expanded. With the old approach I could deal with the expansion status of an entire newly added branch as soon as it was added and then I could forget about it. The normal tree behaviour would take over. With the new API I am going to have to listen for the expanded and collapsed signals to apply the default expansions, but only for the first time that relevant nodes become visible. I guess it's a long shot, but I wondered if anyone had already dealt with anything like this. It feels like it could be solved by adding an "isExpanded" flag to the model nodes, but I don't want to pollute the model with concerns of presentation state. Perhaps I could do it by having some sort of proxy model wrapper that I instantiate in the TreeView, which layers in the flag for the expansion state and delegates the rest to the actual model.

@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

Hi, I think you went the too complicated road: quint16 calculateCrc16Arc(const QByteArray &data) { quint16 crc = 0x0000; const quint16 poly = 0xA001; for (char byte : data) { crc ^= (static_cast<quint8>(byte)); for (int i = 0; i < 8; i++) { crc = (crc & 0x0001) > 0 ? (crc >> 1) ^ poly : (crc >> 1); } } return crc; }

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

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.