It seems that the pyi-type attribute of the modify-argument tag eats the argument default value. I've dug to sources/shiboken6/ApiExtractor/typesystemparser.cpp and the parseModifyArgument function there. However, when I comment the argumentModification.setPyiType(pyiType); line out and re-run python setup.py build --reuse-build --module-subset=Core, I keep seeing that the types are replaced as before. Is the CPP file a wrong place?
I am trying to understand a very specific concept, which I am currently going deep down the rabithole. If one would consider a QComboBox. And this QComboBox is connected via a QDataWidgetMapper. Under the hood there is likely some QItemDelegate that does the magic where the model can have a plain string, and the QComboBox would correctly select the right item. Where / when does this text to currentItemIndex happen? What is basically the slot that is connected?
Bigger question: what should a widget implement so it would not require custom QItemDelegates in the code by the user?
Oh, it calls the system-wide shiboken6. Where does the call come from? It all comes down to the generate_pyi.py script. And I can't go deeper for some reason. There is another virtual environment. Let's check it out…
Thanks a lot! By now, the only question that bothers me is that no changes in the code of shiboken6-generator are applied to the produced *.pyi files. I command python setup.py build --reuse-build --module-subset=Core, it compiles the changes files related to shiboken6-generator, but the files remain the same (although re-written). I'm about to leave the work earlier today. Tomorrow I'll PM you if I may.
@StSav012 Ok. Just for short: You can change the XML. That will generate different binaries when you compile (probably better with a full build), and the executable code will then be introspected by the pyi generator. See you tomorrow.
Would anyone have a hint if there is a possibility to resolve this already 10 year old issue? It basically boils down to that each time setText is applied on a QLineEdit the cursor moves to the end of the widget. The hints on multiple places is: store the cursor position. But the more practical question is, if this is part of a DataWidgetMapper, how could you do this in a non-hacking way, preferably from the model directly.
https://stackoverflow.com/questions/15801259/qlineedit-cursor-moves-to-end-after-textchanged-or-commitdata
@skinkie but that is a Qt question. We are providing the Python wrapper as good as we can, but are not involved in Qt design problems. Maybe that's because of the Qt for Python name. PySide was less misleading.