10 October 2023
id 5248479152Is QDialog used a lot? Can I use Qwidget instead?
Your choice between the two should likely mostly be based on what you're doing at that particular moment. If you're looking for some sort of really common / standard form of input (a yes/no/continue/cancel type question for example, or a popup notification of some sort) then QDialog may be less work, but if you're going for custom input, a complex form, or anything outside QDialog's typical capabilities, then customizing a QWidget may be less work than forcing a more complex QDialog.
Bloo AlienYour choice between the two should likely mostly be based on what you're doing at that particular moment. If you're looking for some sort of really common / standard form of input (a yes/no/continue/cancel type question for example, or a popup notification of some sort) then QDialog may be less wor
I see, Thank you.
alexis jeandetHello I was wondering if there was any plan to use Python 3.12+ subinterpreters in PySide?
My total guess would be that it would just work, as long as the process only instantiated a single QApplication/QCoreApplication/QGuiApplication instance.
I'd like to bring your attention to PYSIDE-1955. Once again, I see that the tr function is missing from the QObject class stubs as described in PySide6/QtCore.pyi. However, the function is mentioned in sources/pyside6/PySide6/QtCore/typesystem_core_common.xml and sources/pyside6/PySide6/glue/qtcore.cpp. How can one be present and missing at the same time?
My best guess is that at line 1810, instead of classmethod="yes", there should be static="yes".
Indeed, the typesystem files. The sources/pyside6/PySide6/QtCore/typesystem_core_common.xml is one of them. I see a lot of tags and their attributes, but I have no idea which ones are allowed and actually used. By now, I've found typesystemparser.cpp, and the code is clear enough to actually use it as a guide. However, an official (and text) one would be great.
The main issue with the stubs is that compared to memory leaks, catching up with the Qt api, or other bits of broken code, it usually end up having a low priority. That's usually the main reason for the delay.
After 6.6.0 I'd like to keep an eye on those open issues, so we can try to cover all the other mistakes. Thanks for the reports, I hope you keep filing them.
Cristián 🥑https://doc.qt.io/qtforpython-6/shiboken6/typesystem.html
Oh, they're on plain sight when I know what to look for. Thanks! And now I'm home and stuck with Could not find a package configuration file provided by "Shiboken6". Apparently, I'll go on with it tomorrow.
Cristián 🥑https://code.qt.io/cgit/pyside/pyside-setup.git/tree/sources/pyside6/PySide6/support
Does the script take the PySide6/typesystems/typesystem_core_common.xml file into account? When I change it, nothing seems to change. It reports that QtCore.pyi got built, but the file looks the same. However, when I did setup.py build ... at work, the file did change.
Cristián 🥑Thanks for your efforts 👍
Thank you for the inspiring words! I'll try something tomorrow. You've already helped me a lot!
Anton YablokovDoes the script take the PySide6/typesystems/typesystem_core_common.xml file into account? When I change it, nothing seems to change. It reports that QtCore.pyi got built, but the file looks the same. However, when I did setup.py build ... at work, the file did change.
IIRC no. The typesystem entry will modify the type information of the generated wrapper. The script will only read the runtime information of the module
Fair point. There are several places with char and char*. I can't be sure that a new piece of logic works until I manually prepare all the corrections. So, it's just quicker to modify the arguments in every single case and only then to make a rule up. As some of the errors wait for half a year, I'd stick to the simplest solution for now. I suppose there is little to no harm to commit a better solution later.
I'll try to do my best until the weekend.