I think you need a negate slot and the type enum is Negate. On Mon 16. Nov 2020 at 02:24, Flower lady fancyflowerlady@users.sourceforge.net wrote: Hey folks, is there a way to support negation for my custom types, e.g., something = -my_type_instance? I have in-place subtraction implemented using the correct flags and overriding iadd in my C++ wrapper for my class, but it seems like negation is a bit different. Is there support for the negation operator using PythonQt::TypeSlots? Sent from sourceforge.net...
I looked this up, you actually need an overloaded __sub__ slot without second object, which returns a negated object. This is due to the code generator and c++, where negation and subtraction is the same -operator
Maybe qmake does not generate correct release vcxproj files for you. You could try to change the pro file to build release only. Google the qmake docs how to configure release only in a pro file. (It was like this years ago, but nowadays I thought release and debug vcxproj settings would be ok). On Fri 12. Jun 2020 at 08:56, Florian Link florianlink@users.sourceforge.net wrote: Yes, the moc required and it only generates addition cpp files that are compiled like the rest of the files. Hm, I would...
Yes, the moc required and it only generates addition cpp files that are compiled like the rest of the files. Hm, I would try to setup my installation anew, remove all tmp files, recreated vcxproj and so on, like you start on a clean machine. On Thu 11. Jun 2020 at 22:55, Flower lady fancyflowerlady@users.sourceforge.net wrote: Hi Florian, glad to hear from you! Unfortunate that you haven't run into this issue. I actually hadn't made any modifications to the MSVC solution before things stopped working....
Sorry but I really don’t know. On Thu 11. Jun 2020 at 21:04, Flower lady fancyflowerlady@users.sourceforge.net wrote: @florianlink, are you okay? You are my shining light. Release build not working Sent from sourceforge.net because you indicated interest in < https://sourceforge.net/p/pythonqt/discussion/631393/> To unsubscribe from further messages, please visit < https://sourceforge.net/auth/subscriptions/>
I mean I never had that problem before and have no idea why it happens for you. What was your last change before it stopped working? On Thu 11. Jun 2020 at 21:04, Flower lady fancyflowerlady@users.sourceforge.net wrote: @florianlink, are you okay? You are my shining light. Release build not working Sent from sourceforge.net because you indicated interest in < https://sourceforge.net/p/pythonqt/discussion/631393/> To unsubscribe from further messages, please visit < https://sourceforge.net/auth/s...
The problem is QVariant, it can only transport registered meta types. So it can transport a PyObject, a PythonQtObjectPtr and a QObject, but not a custom C++ pointer, it would take it as void* and lose type information. So you either convert it first to something that QVariant will handle, or you register its pointer as a meta type, so that QVariant does not lose the type information. On Thu 5. Mar 2020 at 04:57, Flower lady fancyflowerlady@users.sourceforge.net wrote: Hi Florian, I can confirm that...
I am the 'folks'... Well, this is not a very common use case but there are probably multiple solutions... If your CustomType was derived from QObject, you could just create a Qvariant from that pointer. But since it is a C++ only type, you need to get it through the Qvariant without losing the type information. I think you could register a CustomType POINTER meta type, probably PythonQt would then know the type by the meta type id and since it is a registered C++ class, it should know what to do....
Have you tried changing the order of the slots? The more specific overload needs to come first, I think. But yes, you can do a type check for PythonQt wrappers and get the wrapped ptr from a wrapper. There is no example, but you can see it in PythonQtConversion and PythonQtClassInfo how to do this. On Fri 27. Dec 2019 at 06:02, Flower lady fancyflowerlady@users.sourceforge.net wrote: Hi folks, Does anybody know of a way to obtain a custom type from a PyObject* representing that type, assuming it...
Hm, sounds like the destructor of your wrapper has a problem , at least that is probably what the argument frame deletes on reset... Do you do a qRegisterMetaType in your code? Using just the register macro is not enough... On Thu 19. Dec 2019 at 07:10, Flower lady fancyflowerlady@users.sourceforge.net wrote: Thanks Florian, that's very helpful! I have __iadd__, __isub__, and __imul__ operators working, but I'm getting a heap corruption error when trying to implement __add__, after PythonQtArgumentFrame::reset()....
Yes, there are some default Qt slot names that are looked for, but you have to register that your class supports the feature using an enum in registerCppClass (and you need to use the method on PythonQt::priv(), it has more arguments. Have a look at the generated wrappers, e.g. QPoint to see this in action. Regarding repr, PythonQt always looks for py_toString() slots.
Google for super and its problems. Then do direct calls to your base class using BaseClass.xzy(self, arg1, ...). Btw, this has nothing to do with PythonQt itself, it is a pure Python problem.
Look for PythonQtRegisterToolClassesTemplateConverterForKnownClass(QDate) and use it with your fully registered class. Your class needs to be copyable by PythonQt, so it needs to be registered as meta type or maybe it is also enough to have a copy constructor on your wrapper, not sure about that. Registering as QMetaType makes sense anyways.
The easiest way is to use a QList of pointers to YourClass, then you only need to register YourClass with a wrapper/decorator. If you want a QList with YourClass as values, you need to register YourClass as a QMetaType and register a conversion callback for it, have a look how this is done for various list and map types in PythonQt.cpp (there is a macro that registers for vector, QList and QVector with your type). You still need a wrapper/decorator für YourClass for that case. But keep in mind that...
probably you get a C++ pointer back, because your Python object inherits from a C++ class. I think you should reconsider your design and not derive your Python objects from C++ objects. I would create a Python base class and derive from that. If you want to access C++ parts of your application from it, I would create a Qobject that exposes my application Api and pass it to the constructor of the base class. Deriving from C++ objects in Python only makes sense when having full wrappers with virtual...
Yes, I never implemented this. I think it requires special support by PythonQt. On Fri, Nov 8, 2019 at 3:24 PM Max galicarnax@users.sourceforge.net wrote: I had no trouble creating QTreeView and connecting it to QAbstractTableModel on the Python side of PythonQt. Now I need to create a custom model by subclassing QAbstractItemModel, and I just can't make it working. Help is appreciated. Basically, the problem is with the createIndex() method, which accepts row/column and a pointer to a custom tree-item...
C extensions are typically not deployed in debug mode (there are no wheels for them) and building them yourself in debug mode can be difficult or even mostly impossible (scipy for example is really hard to build yourself on Windows). So you can choose between tryping to get a debug build running (which almost nobody of the Python community uses), or to live with a release build. The VS debugger works on release mode as well, so it may not be such a big limitation. Anyways, it is not a PythonQt issue,...
yes, for autocompletion. I have not yet adapted toconsole, becausewe have our own console in our product. It just needs additional GIL scope locks to work with threading.
Threading in PythonQt in fully functional and working. There is one thing that you have to keep in mind: By default, the main thread of your application will hold the GIL, so other threads can only get a time slice when the main thread is running in a Python loop. So what you have to do is to release the GIL after you started up PythonQt and retake it whenever you want to talk to Python from C++ from whatever thread. You release the GIL after the initial PythonQt initialization by: PythonQt::setEnableThreadSupport(true);...
Threading in PythonQt in fully functional and working. There is one thing that you have to keep in mind: By default, the main thread of your application will hold the GIL, so other threads can only get a time slice when the main thread is running in a Python loop. So what you have to do is to release the GIL after you started up PythonQt and retake it whenever you want to talk to Python from whatever thread. You release the GIL after the initial PythonQt initialization by: PythonQt::setEnableThreadSupport(true);...
From a performance and memory consumption point of view, using decorators is the best solution. The decorator QObject only exists once and the decorator slots are cached, so that the lookup is fast. So registering a C++ object and adding decorators is the best. Deriving from QObject will add QObject overhead to your C++ class (which is not much, but if you have thousands of small C++ objects, it's better to avoid it). Using the CPP wrapper factory has extra overhead, since it creates a wrapper QObject...
PythonQt has moved to GitHub: https://github.com/MeVisLab/pythonqt The SF site will stay around, but will not get updates anymore.
PythonQt has moved to GitHub: https://github.com/MeVisLab/pythonqt The SF site will stay around, but will not get updates anymore.
PythonQt has moved to GitHub
Typically you will need to distribute the Python dll(s) and standard libraries together with your application, so that you have your own deployment of Python with your application. There will be a site-packages directory in the libs folder and users can install external Python libs using pip into your deployed Python installation. I would recommend copying the parts the you need from a standard Python installation into your application folder before building the installer. Python does not work without...
removed methods that are not present on all platforms/configurations
applied patch from Uwe Siems (print correct file location in parser)
fixed QTimer wrapping for Qt 5.12
enable QMutexLocker (but __enter__ and __exit__ don't work yet due to PythonQt class wrapper implementation...)
enable QThread (it was removed long time ago but makes sense now that PythonQt support multi-threading)
don't print omitted rvalue methods, we just don't want to wrap them
applied patch provided by Uwe Siems
Look in the preprocessor code pr the master include, I guess one of them is defining it... or you have to add a define that defines it to itself, so that the preprocessor keeps it. On Fri 5. Apr 2019 at 19:37, Allen C Kempe allenck@users.sourceforge.net wrote: I'm not having a lot of luck yet. I thought that I could add some code to check for QT_DEPRECATED on a function but it's not getting called. It seems that there is a pre-processor that is removing the QT_DEPRECATED token from the source. It...
You probably need to initialize PythonQtAll, because it contains the wrappers for QFrame. without generated wrappers, PythonQt can only provide the slots,signals and properties, but not methods that the moc does not handle. Calling PythonQtAll::init() before registering your class should do the trick. You could also pass in the name of the parent clas when registerings, but that is not really needed on Qobjects, I think.
Since you are entering Python from C++, you need to make sure that you hold the GiL, which you can do with placing the PYTHONQT_GIL_SCOPE into the scope where you communicate with Python or PythonQt (and even when you talk to a PythonQtObjectPtr, because it will do non-thread-safe ref counting of the PyObject). So you have to place PYTHONQT_GIL_SCOPE into your run method. An important thing to understand is that even it is multi threading, only one thread can talk to Python at a time, which is why...
Thanks for reporting, could you say which Qt version you are using? I am not actively working on PythonQt right now, so maybe you can have a look by yourself.
No, that is currently not implemented. You could expose non-QObject C++ objects and write wrappers/decorator classes for them. Or you could modify PythonQtClassInfo to stop inheritance traversal before QObject.
I think you have to look into remote debugging, e.g. like in PyDev /Eclipse or PyCharm. Running a debugger in the same process with Qt Gui is not possible, because the main thread will be blocked, so your Gui can't update. You need a second process which shows the Debugger and has a UI, typically that application is the text editor as well, so that you can set breakpoints and show where the cursor is located. Maybe using an existing remote debugger would be a simple solution for you (but less integrated...
Qt does not allow to create widgets outside the GUI thread, this a Qt limitation, not a Python limitation.
I will send you a private message.
We developed our own TextEditor and Debugger using Qt. We use Jedi (in an extra process) for the autocompletion and goto definition etc. QSyntaxHighlighter for the highlighting... Debugger uses Python trace callbacks. Unfortunately it's all closed source. I dont't know a good open source option.
I don't have time to fix this right now, but I added a bug report in our internal bug tracker.
use C++11 {} initializer for returnValue
fixed problematic self deletion without having the GIL and while iterating the loop
added missing GIL scope
reimplemented argument frame caching (previous approach was not thread-safe when GIL is used)
fixed linux compilation problem
Hm, there are various ways, but all require some work, especially if you want to be able to modify the data from both sides... Maybe the easiest would be to use a Python array (see standard library) of the desired type. But PythonQt does not support automatic conversion, so you would need to use a PyObject pointer in your slot and use the Python C api to talk to it from C++. Another common way is to use numpy arrays, but that will require the numpy installation and you would need to use the numpy...
You can't. You could change the interface to take a QVector or QList of ints. The any sequence in Python will be converted to that list/vector.
You can call it before or after init (because it only stores static bools). But you have to call it at least before releasing the GIL and before starting threads. On Thu, Sep 6, 2018 at 9:45 AM Joerg Kreuzberger kreuzberger@users.sourceforge.net wrote: Is there any relation to PythonQt::init() i assume directly after PythonQt::init() Python GIL Handling with PythonQtAll Sent from sourceforge.net because you indicated interest in < https://sourceforge.net/p/pythonqt/discussion/631392/> To unsubscribe...
Hm, does your wrapper have a destructor slot (I forgot how they are named, delete_XYZ)? Because that is what PythonQt will use to destroy it (otherwise it can't destroy it).
No, there is no such mechanism. PythonQt could have a callback to notify you when an object wrapper is deleted, but it would not know where the object came from.
The default ownership of returned objects is C++, so your object is not deleted by Python, just the wrapper to it. If your get() method returns a new object and you want Python to delete it, you can use the ownership templates in PythonQt.h http://pythonqt.sourceforge.net/classPythonQtPassOwnershipToPython.html#aaad0d16be54de03dbd53c5184f1318eb the templates don't do anything, but tell PythonQt that a returned pointer should change ownership. The shell callback is something else, it is used to set...
I did some more work on this. The thread support is now compiled in by default, but needs to be enabled using: PythonQt::setEnableThreadSupport(true)
compile thread support by default
if there is not promoter, we can't call the promoted functions
Thanks, I merged your fix... I wonder if all places in the importer that return NULL should set an error. Starting with Python 3.6 we don't use the PythonQtImporter anymore in our product, we switched to using the default Python importer with some monkey patching to allow signed files. I will keep it in for backward compatibility, but for Python 3.x I recommend not to use it, since it behaves substantially different from the Python 3 import mechanism (regarding pyc cache directories etc.).
added error on failed load
Ah, maybe you need to run it from a different directory? I typically start it inside the generator directory, but don't enter the Release subdir... I don't know if that is relevant.
Hm, do you have the correct Qt dlls in the PATH (the ones that you built the generator with)? It might also help to unset the MSVC environment variables, especially INCLUDE or the like. I ran the generator with 5.6 and 5.11 on msvc2015-64, so it should work in general.
I now updated the wrappers for 5.6 and 5.11 with the new generator containing the GIL macros. I also added override keyword parsing to the C++ parser, since Qt uses these a lot nowadays. Regarding thread support, the state is as this: I think I found the most prominent places and added GIL / Thread save/restore to them the PythonQt API still needs the GIL to be taken by the caller and I am still thinking about a good design for a safe api... Just locking every call with the GIL is too expensive....
I now updated the wrappers for 5.6 and 5.11 with the new generator containing the GIL macros. I also added override keyword parsing to the C++ parser, since Qt uses these a lot nowadays. Regarding thread support, the state is as this: I think I found the most prominent places and added GIL / Thread save/restore to them the PythonQt API still needs the GIL to be taken by the caller and I am still thinking about a good design for a safe api... Just locking every call with the GIL is too expensive....
I now updated the wrappers for 5.6 and 5.11 with the new generator containing the GIL macros. I also added override keyword parsing to the C++ parser, since Qt uses these a lot nowadays. Regarding thread support, the state is as this: I think I found the most prominent places and added GIL / Thread save/restore to them the PythonQt API still needs the GIL to be taken by the caller and I am still thinking about a good design for a safe api... Just locking every call with the GIL is too expensive....
added rvalue assignment and copy constructor to PythonQtObjectPtr
recreated wrappers for Qt 5.11
recreated wrappers against Qt 5.6.3 with GIL macros and override handling
re-added removed methods that have not been removed previously
See mistake #2 http://www.acodersjourney.com/2016/08/top-15-c-exception-handling-mistakes-avoid/
As far as I know C++ the local variables in the try block are all destroyed before getting into the catch clause, which means that the scope object gets deleted in time and restores the thread state.
added support for override
switched to using macros for scopes
switched to using macros for scopes
I'm still working on it, so please wait a bit, I will post when I'm finished. I could regenerate Qt 5.6 and Qt 5.11 wrappers. If you need older wrappers, you need to run the pythonqt_generator. (It is really not hard to run it, just build it and set your QTDIR to the Qt version that you want to wrap, then run the generator without further commandline arguments inside of the "generator" directory).
add GIL scope to virtual functions
initial GIL support (needs to be enabled via defines)
for compatibility, keep the obsolete or deprecated enum values
There is just the code and the examples. The main design idea is to do as much as possible with the metaobject model and dynamic calls vs generated code. And the generated code reuses the moc by using slots for the wrapped functions.
Yes, it works for me (I ran it with Python 3.6 and Qt 5.11 on vs2015). On Fri 24. Aug 2018 at 10:31, Joerg Kreuzberger kreuzberger@users.sourceforge.net wrote: Did the test really run without errors? I got error in test exectuion in the importer test, where "bla" module is tried to imported (but not found). There i get a python exception that a function is returning NULL without error / exception set.... Build error in Building PythonQtTests with r477 Sent from sourceforge.net because you indicated...
I discussed this with a colleague and we think the best way will be to add some helper scope classes which ensure/release the GIL. Then we can have two implementations for the scope classes, an empty one which gets optimized away and one with threading enabled which does the GIl work. We would still use PythonQt without the GIL scopes in my company and you can use it with the GIL. And all the GIL stuff would be in a single file. I would place the scope objects at the central places were PythonQt...
new wrappers for Qt 5.11 (no QtWebView wrappers, since QtWebView is not part of Qt 5.11 anymore)
support Qt 5.11
added some missing classes that were added since Qt 5.6
help generator to work on Qt 5.11.1
Sorry to disappoint you, but PythonQt currently does not support multithreading at all. Years ago someone (I think there is a post here on the forum) tried implementing it, but it never reached a state which I could merge in. To support multithreading in PythonQt, there are two sides to it: ensure that the GIL is ensured whenever we enter into Python from C++ code and ensure that the GIL is released and retaken when we enter C++ code from Python This includes things like the PythonQtObjectPtr, which...
I fixed that on svn trunk. I should have compile/run the test on my last commit...
Myself being the "maintainers", I removed the WindowOkButtonHint and WindowCancelButtonHint enums which were used on Windows CE only. This also brought to light that the pythonqt generator did not discard enum values that were marked as reject in the xml files. I now added that to the generator. This means that the next time you (or I) generate wrappers, many enums that were marked as obsolete in Qt will be removed from the wrappers as well.
(re-)added support for rejecting enum value
removed WindowOkButtonHint and WindowCancelButtonHint, which have been removed from Qt 5.9
added missing abstract virtual
I fixed this on the svn trunk, I should not have used PyImport_FixupBuiltin, since it is a private API...
reverted usage of _PyImport_FixupBuiltin
added support for attribute lookup error callback
I added the patch to the trunk.
added patch from forum (stack unwinding)
You can put them into a class and make them static methods. Then the generator can wrap them. Pure C functions are not supported.
make sure that Python.h is always included first
I cleaned that up and commited on svn trunk.
I will have a look, you post was stuck in the admin moderation. Strange fact: the code builds on MacOs on our servers...
Yes, that is possible but not well documented, since it not the main feature of PythonQt. It was discussed in this thread: https://sourceforge.net/p/pythonqt/discussion/631392/thread/d753683f/ You can also just make your class a QObject with slots and properies and use it without a wrapper (have a look at the example directory). Or you can program your wrappers manually , as seen 8n the examples.
No, there is no such list, but you are free to compile one. You can use dir() to get a listing of all classes in QtCore and compare them to C++ Qt. Or you can have a look at the generator xml files and look for rejected classes.