About Qt6 #13
Comments
|
No, we have not looked at Qt 6 yet. But I guess basic features like the moc
and signals slots will stay, so it should not be hard to keep PythonQt
working. The wrapper generator is another thing, it might be needed to be
rewritten, e.g. using PySide shiboken technology.
…On Thu 18. Jun 2020 at 08:07, Hu Shubin ***@***.***> wrote:
Qt6 is coming. Are there any plans to update PythonQt to support qt6?
thanks.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#13>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKHPHARXAY7AEY6XQJVZDLRXGVLPANCNFSM4OBH6J4Q>
.
|
|
Thanks for your respond |
|
@florianlink 🙏 Thank you for supporting this project. Would you be willing to check-in generated wrappers for Qt 5.15? It is the last minor version of Qt 5 before Qt 6. This would be helpful as a final point before going to Qt 6 for this project. |
|
Thank you @florianlink for that answer. I'm thinking about using pythonqt for another project, but was not shure about the wrapper generator because the last official commit at qt side was 3 years ago. |
|
I'm interested in helping port to PySide for Qt6. @florianlink Do there exist a communication channel if I have some questions regarding the code? |
|
No, I am probably the only one you can ask... florianlink at google mail
…On Fri 6. Nov 2020 at 16:29, Murmele ***@***.***> wrote:
I'm interested in helping port to PySide for Qt6. @florianlink
<https://github.com/florianlink> Do there exist a communication channel
if I have some questions regarding the code?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#13 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKHPHE3BQN6RIR4V42FITTSOQI57ANCNFSM4OBH6J4Q>
.
|
|
@florianlink is there any word on Qt 5.15 generated wrappers being added? I'm not quite sure how to invoke It throws a lot of warnings and then a lot of classes are missing in the result. For instance, QtGui builtin is missing QFont, QMatrix, QPen, and more. I'm not sure if there is something wrong with my environment or if the typesystem_*.xml files need updating. I've turned up the debugging but it doesn't provide any clues. Is there any advice you can provide on how to fix this? Here's some output: |
|
I should add, I'm able to successfully build and use the 5.11 generated wrapper with 5.15.2. I just need to access a new method on QJSEngine that was added in 5.12. cc: @usiems |
|
Probably some newer C++ features that the generator parser stumbles
over... I did not yet look into it.
…On Wed 30. Dec 2020 at 21:57, David K. Hess ***@***.***> wrote:
I should add, I'm able to successfully build and use the 5.11 generated
wrapper with 5.15.2. I just need to access a new method on QJSEngine that
was added in 5.12.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#13 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKHPHAGWETSTXIE2VIE7I3SXOH5BANCNFSM4OBH6J4Q>
.
|
|
@florianlink Having been 1 year since the last comment on this thread, is PythonQt still an active project with plans for Qt6 support? Or are developers encouraged to use Pyside6 instead? |
|
Well, eventually MeVisLab will switch to Qt6, at which point we will surely
port PythonQt… but I can’t tell when MeVisLab will switch or someone else
looks into this… as far as I know Pyside does not work for embedding
Python, but haven‘t looked at it for a while…
…On Sun 2. Jan 2022 at 18:37, James Butler ***@***.***> wrote:
@florianlink <https://github.com/florianlink> Having been 1 year since
the last comment on this thread, is PythonQt still an active project with
plans for Qt6 support? Or are developers encouraged to use Pyside6
<https://pypi.org/project/PySide6/> instead?
—
Reply to this email directly, view it on GitHub
<#13 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKHPHHNRCQX4LGDQ6DRN2TUUCEMFANCNFSM4OBH6J4Q>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I haven't looked into this for a very long time either, but this code indicates that pyside should now be usable from inside a C++ application. https://github.com/pyside/pyside-setup/tree/dev/examples/scriptableapplication |
|
@florianlink Thank you for all your work in this project. Do you have more information about when Qt6 support may become available? |
|
Hello @florianlink, in my company we will need PythonQt to build with Qt6.2 very soon. Therefore we thought to participate to this awesome project. If the approach end up being an "OK idea", I might have few questions later on (especially about PythonQtShell_ classes). Best regards, |
|
@florianlink Do you have any update on this? Are you expecting external support (funding or contributions with implementation, testing, etc.) to make PythonQt work with Qt6? |
|
@florianlink I'm trying to remain hopeful, due to the lack of updates and any specific information for over 3 years, I'm beginning to worry. Qt5 open-source support has ended long time ago and even LTS commercial support will end within 2 years (https://www.qt.io/blog/qt-5.15-extended-support-for-subscription-license-holders). So, while there are no serious problems right now, the risk of thing starting to break is increasing and we definitely need a solution within 2 years. We haven't heard from you for on this thread for 1.5 years - are you still around? It would be useful even if you could just confirm that updating of PythonQt for Qt6 is still the plan (that MeVisLab doesn't plan to switch to Python for Qt), but if you could share some more details then it would be even better. Thank you! |
|
Not being @florianlink, I can nonetheless state that the plan to add Qt6 support to PythonQt has not changed. As for the time line - this should be done in a few months, latest at the end of the year. |
|
Just of note (you know me by now) is that Qt 5.15 ships with RHEL 9 so it will have commercial support by RedHat until at least 2032. So there are probably more people like me in production environments who wish that PythonQt keeps supporting Qt 5 for quite a while. RHEL 10 may ship with Qt 6 but RHEL 10 is still many years off and RHEL 7/8/9 will remain in use. So nothing against adding Qt 6 support but just as Python devs officially dropped support for Python 2.7 years ago doesn't mean it goes away. RHEL 7 still ships with Python 2.7 and is under active commercial support. Qt 5.15 will be in use and commercially supported by third parties for years beyond whenever Qt company drops support. Also, if there isn't already, Qt 5 will likely be forked and developed separately due to the license change with Qt 6. Qt company dropped QtWebKit after Qt 5.6 but it is still developed and maintained by original developer and still ships with most major Linux distributions up to this day. Qt 5 will live on, likely supported and maintained by some open-source group who does not like the Qt 6 license change. |
|
@mrbean-bremen and @he-hesce I really appraciate your quick and insightful answers.
@mrbean-bremen This is very reassuring to hear. By the end of the year sounds great.
Thanks for the information. RHEL is an important platform, so this will be useful, but there are other linux flavors and Windows and macOS that our application should work on, so staying on Qt5 for too long seems like a risky strategy.
Qt 5/6 will likely to diverge over time, so backporting or redoing fixes and improvements from Qt6 could become harder and harder. It would be great if a stable open-source Qt distribution lived on, but might be unsustainable in the long term. They might also not care about Windows and macOS support. We'll have to see. |
|
@he-hesce - this is not about supporting Qt 5 anymore, just about branching policy. We may have separate branches for Qt5 and 6 (both active), or a single branch as now. Both approaches have pros and cons. |
FYI, as user of PythonQt in 3D Slicer, either a single branch or two separate branches are good for us. You can choose whichever is easier for you to develop and maintain, |
|
@mrbean-bremen : It's up to you as product owner to decide on branching policy. There are as you say pros and cons. A definite con for two branches is that bug fixes needs to be applied in two places and patches to Qt 6 branch for a bug may need to be ported to the other branch if the code is too different. Also a single branch is easier to keep tested with good coverage as you benefit from cross-testing, i.e., people testing with Qt 6 will also test the a lot of the same code used for Qt 5 and hence you get better testing coverage (as in number of eyes/systems). To me it doesn't matter much as we will be using Qt 5.15 for another 10 years at least. May look at Qt 6 in a decade or so or put some toes into the water with RHEL 10 eventually (if it ships with Qt 6). Building two separate branches for us in the same repo is also not a problem. However, as a software engineer and open-source contributor, I also always like to have a community and long-term view on things and speak up for those who remain silent or are without a voice in this forum :-) |
|
Hello, my employer (FotoKem Inc.) had a need to upgrade this library to build against Qt6 for use in one of our products, and so I did that. Our application runs Python scripts internally, and those scripts use our application's own QObject-derived objects, but don't use any Qt objects. So we do not need the generator, or its generated c++ meta-code, or the libPythonQt_QtAll library. I was able to fix all of the Qt6 compatibility issues in the core PythonQt library without too much trouble, and remove all of the dependencies with the generated code to build a functional libPythonQt-Qt6 library. My employer has decided to contribute these changes back to the community for others to use as well. The Qt6 compatibility changes are in my PythonQt fork here: https://github.com/richard42/pythonqt This may also be useful to the upstream MeVisLab team to use as a starting point for the Qt6 branch. To build the library, just clone my fork, run "qmake" with the appropriate options from the root folder, then "make all" from the "src" sub-folder. |
|
Thank you - that may indeed help us! Contributing changes back to the community is always a Good Thing ™️, and we appreciate that. |
|
Yes, all of my changes are backwards-compatible to Qt 5.15.2. Some of the changes might not work with older Qt5 versions, for instance I had to switch usages of QDateTime::toTime_t() to toSecsSinceEpoch(), which was introduced in Qt 5.8. But I'm pretty sure that all of these changes will work at a minimum in Qt 5.12, maybe even older. |
|
Thanks! Maybe you can just make a PR from your changes - not for immediate merge, but to have a better look at the diff and to see what the CI has to say... |
|
I broke up the changes into 5 separate commits, which can be seen here: https://github.com/richard42/pythonqt/commits/master I assume that you only want the middle commit in the PR? (Qt6 compatibility fixes for core PythonQt library) |
Thanks - yes, that looks right. It will not work with Qt6 of course, but it would still good to have as a PR for better comparison, and to see which of the CI actually breaks with it. |
|
Okay, the new pull request is here: |
From what I can tell, this is our use case too. PythonQt became a convenient way for us to not worry about how Python bindings were made for our Qt C++ code. Since we're just using PythonQt to enable writing Python scripts that pre-configure a user interface when the application opens up, we're evaluating other options that will let us move to new versions of Qt more easily on our own timeline. So far, we're having good luck with PyBind11. This gives us a way to have compiler-supported bindings without a generator, which reduces overall complexity. While this does lock us into one version of Python, it's not a problem for us. Embedding the Python interpreter into our application to evaluate our Python scripts also isn't hard from there with PyBind11. We can also pre-import the compiled module for these scripts and inject our Qt objects into the global Python namespace dictionary if needed. We tried going down the Shiboken route, but the complexity there is pretty high and it has a bit of a learning curve. While it supports everything about Qt, we still opted to use PyBind11 even though it doesn't support signals and slots to keep things simple. PyBind11 can still create bindings to slots, which we expose as a part of the Python API for our module from C++. I would love for something like PythonQt to be officially adopted by the Qt project. It's a shame that it's not since the idea of using Python to automate an interface is pretty awesome. |
|
Just for reference: all changes related to Qt6 as provided by @richard42 and @jamesobutler are now on the qt6 branch.
While this would be nice, it is unlikely given the small user base of PythonQt compared to PyQt & Co. |
|
@mrbean-bremen I have been unable to find where https://github.com/MeVisLab/pythonqt/tree/qt6 has gone as the link 404s now. Where is the Qt 6 support located? |
|
Ah, should have mentioned it here. It has been merged back to the main branch, as it still works for Qt 5, and some of the changes also benefit Qt 5 (especially Qt 5.15). |
|
Note that the current master supports Python 5.15 and 6.5 - there will be a release (or probably first a pre-release) soon. As with older versions, not all classes and methods are supported, and for Qt6, most of the Add-On modules are not included. They can be included on demand later. It would be helpful if anyone else could test the current state to find some of the bugs that are without doubt included... |
|
I generated bindings for Qt 6.6.1. |
|
I don't think that this is specific to Qt6 - you need an application to create a widget. Did this work with Qt5? And does it work in release mode? If this is a new problem, please write a separate issue with the code that shows the problem. |
|
Yeah it turns out that I just had my debug and release binaries mismatched. It works fine so far. |
|
I'm closing this, as Qt6 is supported now. |
Qt6 is coming. Are there any plans to update PythonQt to support qt6?
thanks.
The text was updated successfully, but these errors were encountered: