On 2019-09-02 13:36-0700 Alan W. Irwin wrote:
Hi António:
Your fix of the serious Qt5 font configuration bug for PLplot made our
Qt5 results in PLplot-5.15.0 essentially as good as our Qt4 results
for the first time ever. So ever since that release it has been on my
mind to greatly reduce the complexity of our build-system *and*
testing of our Qt and PyQt components by only supporting Qt5 (i.e.,
dropping our support for Qt4).
The current build-system situation is Qt4 is looked for first, but if
it is not found Qt5 is used as a backup with the exception that Qt5 is
forced if the user specifies -DPLPLOT_USE_QT5=ON (which defaults to
OFF). So my proposed plan to reach the above goal with minimum
disruption for users is the following:
* PLplot-5.16.0. Use the exact same build system logic except that 4
and 5 are swapped. That is Qt5 is looked for first, but if it is
not found Qt4 is used as a backup with the exception that Qt4 is
forced if the user specifies -DPLPLOT_USE_QT4=ON (which defaults to
OFF). Warn in the release notes of this change and the
corresponding replacement of the PLPLOT_USE_QT5 option with
PLPLOT_USE_QT4 and also mention we plan to deprecate Qt4
support in the next release and remove it in the next release
after that.
To Hazen and António:
@António: Thanks for your support (in a different post) for my preliminary
roadmap for dropping Qt4.
@Both: In the event, the above "5.16.0" step was much easier than the
intrusive change I described above. Instead, all I essentially did
was to change the default value for PLPLOT_USE_QT5 from OFF to ON.
(See the Qt-related change in the new (commit 24d0bdf70) version of
README.release for the details.)
Revised rest of the roadmap.
* PLplot-5.17.0. Officially deprecate Qt4 in the release notes and
also say we intend to drop it for 5.18.0 there. The only change
from the above build system logic is an additional deprecation warning to
the user when they specify -DPLPLOT_USE_QT5=OFF and no
fall back to Qt5 if Qt4 cannot be found.
* PLplot-5.18.0 (or whenever we decide to pull the plug on Qt4
support considering the smoke issue below). Completely remove
support for Qt4 (which will finally achieve the desired
build-system and test simplifications which is the fundamental
motivation for this change).
@Hazen: In light of the smoke binding issue we should discuss this
still tentative roadmap further.
That smoke binding issue is bindings/qt_gui/smoke/ needs to be removed
when we drop support for Qt4 because [smoke is not available for
Qt5](https://news.ycombinator.com/item?id=20636312). You apparently
implemented the PLplot smoke binding because that binding was needed
by another independent project of yours.
Assuming you do want to develop a Qt5-based binding which would
satisfy the needs of your independent project in the same way the your
current Smoke Qt4-based binding does, from the "history lesson" in the
above URL it appears one possible way forward for Qt5 bindings of any
kind is [Shiboken](https://wiki.qt.io/Qt_for_Python/Shiboken). For
example, Shiboken is used to implement pyside2 (python binding for
Qt5), but I have no clue how difficult it would be for you to replace
your smoke binding with a corresponding Shiboken binding. Anyhow,
please let me know whether you plan to replace the above smoke binding
once it is removed as part of dropping our Qt4 support. And your
input on the timing of dropping our Qt4 support is needed as well.
By the way, when that support is dropped our pyqt4 binding will have
to be removed as well, but that should not be an issue at least for
now since our current pyqt5 binding seems to work OK. But that pyqt5
binding does depend on the external pyqt5 project which depends on
another external project (sip). So our pyqt5 binding will become
vulnerable if either the external projects pyqt5 or sip becomes
unmaintained.
The above pyside2 project is a recent competitor to pyqt5. And
contrary to the expectations of the above 2017 discussion, pyside2 has
been released and is apparently going strong. (For example, Debian
Buster has many pyside2 packages and the necessary shiboken packages
to support pyside2.) Therefore, if you were interested, I would
encourage you to implement a pyside2 binding and pyside2_example
corresponding to pyqt5_example just in case it turns out that external
pyqt5 of sip ever goes the same way that smoke has gone.
Alan
__________________________
Alan W. Irwin
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
