From hexray blog
Finally they took a good move here.
IDAPython + PySide/PyQt: future plans
Posted on April 9, 2015 by arnaud
Intended audience
IDAPython plugin writers who are using the PySide Qt bindings.
PySide: some background
For some time now it has been possible, through IDAPython, to use PySide bindings to the Qt libraries that are shipped with IDA.
Those PySide bindings were first placed on Hex-Rays’s website and, since we noticed a considerable interest for them, we later decided to ship them with IDA (starting at IDA 6.6.)
What about PyQt?
The choice of PySide over PyQt was essentially due to incompatibilities between the licensing model of PyQt, and that of Hex-Rays.
The problem
PySide appears to have pretty much stopped evolving, and now remains stuck with Qt 4 (i.e., the 4.8 branch.)
PySide isn’t available for Qt 5 and, as of today, the last update of the PySide roadmap dates back to “March 26, 2013″.
There is still some activity on the PySide mailing list, but despite that, not much seems to be happening (and the latest release is from 1 year ago.)
This is very problematic for us as Qt 4 is becoming more and more irrelevant by the day, and we would love to move to Qt 5.
We could, in theory, invest in porting PySide to support Qt 5, but it would probably lead us to an undesirable situation where PySide is pretty much used and maintained by Hex-Rays only.
Meanwhile, in PyQt land
In the meantime, the PyQt people at http://www.riverbankcomputing.co.uk/ have changed their licensing options, and after having contacted them recently, we have found that we can now consider the following:
Our plan
Our plan is to roll, in a few days, IDA 6.8 that still depends on Qt 4, and still ships with PySide.
The release after that (i.e., 6.9) will then depend on Qt 5, and come with PyQt.
What that means for developers
Thankfully, the interfaces of PySide and PyQt are highly compatible, and thus it should not be necessary to rewrite your plugins from scratch (in fact, very little should have to be modified.)
I would recommend you to stay tuned to the Hex-Rays forums, so that you can participate in the beta program for IDA 6.9 once it is announced. That will give you the possibility of porting your tools to PyQt before IDA 6.9 is released. We will also provide guidance on how to approach that porting effort (even though, once again, it should be fairly small.)
As you may already know, we are very reluctant to any kind of API/compatibility breakage. But unfortunately, it seems we simply don’t have a choice in this particular case.
mend you to stay tuned to the Hex-Rays forums, so that you can participate in the beta program for IDA 6.9 once it is announced. That will give you the possibility of porting your tools to PyQt before IDA 6.9 is released. We will also provide guidance on how to approach that porting effort (even though, once again, it should be fairly small.)
As you may already know, we are very reluctant to any kind of API/compatibility breakage. But unfortunately, it seems we simply don’t have a choice in this particular case.
Finally they took a good move here.
IDAPython + PySide/PyQt: future plans
Posted on April 9, 2015 by arnaud
Intended audience
IDAPython plugin writers who are using the PySide Qt bindings.
PySide: some background
For some time now it has been possible, through IDAPython, to use PySide bindings to the Qt libraries that are shipped with IDA.
Those PySide bindings were first placed on Hex-Rays’s website and, since we noticed a considerable interest for them, we later decided to ship them with IDA (starting at IDA 6.6.)
What about PyQt?
The choice of PySide over PyQt was essentially due to incompatibilities between the licensing model of PyQt, and that of Hex-Rays.
The problem
PySide appears to have pretty much stopped evolving, and now remains stuck with Qt 4 (i.e., the 4.8 branch.)
PySide isn’t available for Qt 5 and, as of today, the last update of the PySide roadmap dates back to “March 26, 2013″.
There is still some activity on the PySide mailing list, but despite that, not much seems to be happening (and the latest release is from 1 year ago.)
This is very problematic for us as Qt 4 is becoming more and more irrelevant by the day, and we would love to move to Qt 5.
We could, in theory, invest in porting PySide to support Qt 5, but it would probably lead us to an undesirable situation where PySide is pretty much used and maintained by Hex-Rays only.
Meanwhile, in PyQt land
In the meantime, the PyQt people at http://www.riverbankcomputing.co.uk/ have changed their licensing options, and after having contacted them recently, we have found that we can now consider the following:
- Hex-Rays can acquire PyQt licenses
- with those, we can build PyQt, and ship it with IDA
- IDA users can make use of PyQt themselves
- is widely used, and has momentum
- supports Qt 5
Our plan
Our plan is to roll, in a few days, IDA 6.8 that still depends on Qt 4, and still ships with PySide.
The release after that (i.e., 6.9) will then depend on Qt 5, and come with PyQt.
What that means for developers
Thankfully, the interfaces of PySide and PyQt are highly compatible, and thus it should not be necessary to rewrite your plugins from scratch (in fact, very little should have to be modified.)
I would recommend you to stay tuned to the Hex-Rays forums, so that you can participate in the beta program for IDA 6.9 once it is announced. That will give you the possibility of porting your tools to PyQt before IDA 6.9 is released. We will also provide guidance on how to approach that porting effort (even though, once again, it should be fairly small.)
As you may already know, we are very reluctant to any kind of API/compatibility breakage. But unfortunately, it seems we simply don’t have a choice in this particular case.
mend you to stay tuned to the Hex-Rays forums, so that you can participate in the beta program for IDA 6.9 once it is announced. That will give you the possibility of porting your tools to PyQt before IDA 6.9 is released. We will also provide guidance on how to approach that porting effort (even though, once again, it should be fairly small.)
As you may already know, we are very reluctant to any kind of API/compatibility breakage. But unfortunately, it seems we simply don’t have a choice in this particular case.