Menu
▾
▴
plplot-devel
|
From: Alan W. I. <Ala...@gm...> - 2019-09-02 20:36:43
|
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. * PLplot-5.17.0. Deprecate Qt4, i.e., use it as a fall back from Qt5 *only* if the users sets -DPLPLOT_QT4=ON. Warn in the release notes of this change and also warn we plan to remove support for Qt4 in the next release. * PLplot-5.18.0. Completely remove support for Qt4 which will finally achieve the desired simplifications mentioned above. As someone here with a large familiarity with Qt, I would appreciate you letting me know if you forsee any trouble with this overall plan to remove our Qt4 support. And comments on this plan from the other PLplot developers here are also encouraged. I will likely implement the 5.16.0 part of the above plan late this week if there are no strong disagreements expressed here in the next several days. 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 __________________________ |
|
From: António R. T. <ar...@gm...> - 2019-09-02 20:53:12
|
Hi Allan, I really think that is safe to remove qt4 support. Sooner or later qt4 will not be available by default in a normal linux distribution. So I agree with your proposed roadmap. cheers, On Mon, Sep 2, 2019 at 9:36 PM Alan W. Irwin <Ala...@gm...> 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. > > * PLplot-5.17.0. Deprecate Qt4, i.e., use it as a fall back from > Qt5 *only* if the users sets -DPLPLOT_QT4=ON. Warn in the release > notes of > this change and also warn we plan to remove support for Qt4 in > the next release. > > * PLplot-5.18.0. Completely remove support for Qt4 which will finally > achieve the > desired simplifications mentioned above. > > As someone here with a large familiarity with Qt, I would appreciate > you letting me know if you forsee any trouble with this overall plan > to remove our Qt4 support. And comments on this plan from the other > PLplot developers here are also encouraged. > > I will likely implement the 5.16.0 part of the above plan late this > week if there are no strong disagreements expressed here in the > next several days. > > 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 > __________________________ > -- António Rodrigues Tomé Universidade da Beira Interior Instituto D. Luís (lab associado) email address: ar...@gm... ar...@ub... http://www.researcherid.com/rid/A-5681-2013 |
|
From: Alan W. I. <Ala...@gm...> - 2019-09-06 23:56:40
|
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
__________________________
|
|
From: Hazen B. <hba...@ma...> - 2019-09-07 01:34:13
|
> > @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. No problem, go ahead and remove the smoke bindings. -Hazen |
|
From: Alan W. I. <Ala...@gm...> - 2019-09-07 07:23:25
|
On 2019-09-06 21:33-0400 Hazen Babcock wrote: > >> >> @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. > > No problem, go ahead and remove the smoke bindings. Hi Hazen: Thanks for that clarification. As a result, the timing of the roadmap for removing everything to do with Qt4 (including our smoke and pyqt4 bindings) from PLplot is much more certain and now reads as follows: Revised roadmap: * PLplot-5.17.0. Officially deprecate everything in PLplot that is related to Qt4 in our release notes and also mention there the planned dropping of everything in PLplot that is related to Qt4 in PLplot-5.18.0. Despite those planned remarks in the release notes, the only change from the Qt-related build system logic for 5.16.0 that has just been committed will be a deprecation warning to the user when they specify -DPLPLOT_USE_QT5=OFF. * PLplot-5.18.0. Drop everything in PLplot that is related to Qt4. That essentially means removing all logic stanzas in our build system that are currently only exercised when -DPLPLOT_USE_QT5=OFF. The removal of our smoke binding and our pyqt4 binding (only available when -DPLPLOT_USE_QT5=OFF) will be part of this change. The result of this change should be a substantial simplification of our build system. Also, our current lack of testing of the -DPLPLOT_USE_QT5=OFF case (because I don't have time to test both -DPLPLOT_USE_QT5=ON and -DPLPLOT_USE_QT5=OFF) obviously will no longer be a concern after this change. 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 __________________________ |
|
From: Jonathan W. <jw...@ju...> - 2019-09-07 07:16:35
|
Hi Alan On Mon, Sep 02, 2019 at 01:36:30PM -0700, Alan W. Irwin wrote: > As someone here with a large familiarity with Qt, I would appreciate > you letting me know if you forsee any trouble with this overall plan > to remove our Qt4 support. And comments on this plan from the other > PLplot developers here are also encouraged. Depending on the timing between the versions which make up the plan, I suspect this will be fine. FYI Slackware does not (yet) ship Qt5 (there are various reasons for this, the discussion of which is outside the scope of this thread). There is a third-party source of Qt5 for Slackware though which users can install if they have a need for Qt5. Therefore once PlPlot 5.18.0 rolls around, plplot will no longer be usable under a standard Slackware installation unless the Qt5 packages from the AlienBob repository are installed. The other option (which I'm personally *really* hoping for) is that Qt5 ships in Slackware by that time. If this happens, the yet to be released Slackware 15 will be the first Slackware version to ship Qt5 as part of the distribution. Given the low number of users of plplot on Slackware I don't believe your plan should be changed as a result of the above information, especially since there is a viable workaround. I mention it only for completeness so people are aware of the possible impact and the steps needed to circumvent it. Regards jonathan |
|
From: Alan W. I. <Ala...@gm...> - 2019-09-07 09:52:22
|
On 2019-09-07 16:46+0930 Jonathan Woithe wrote: > Hi Alan > > On Mon, Sep 02, 2019 at 01:36:30PM -0700, Alan W. Irwin wrote: >> As someone here with a large familiarity with Qt, I would appreciate >> you letting me know if you forsee any trouble with this overall plan >> to remove our Qt4 support. And comments on this plan from the other >> PLplot developers here are also encouraged. > > Depending on the timing between the versions which make up the plan, I > suspect this will be fine. FYI Slackware does not (yet) ship Qt5 (there are > various reasons for this, the discussion of which is outside the scope of > this thread). There is a third-party source of Qt5 for Slackware though > which users can install if they have a need for Qt5. > > Therefore once PlPlot 5.18.0 rolls around, plplot will no longer be usable > under a standard Slackware installation unless the Qt5 packages from the > AlienBob repository are installed. The other option (which I'm personally > *really* hoping for) is that Qt5 ships in Slackware by that time. If this > happens, the yet to be released Slackware 15 will be the first Slackware > version to ship Qt5 as part of the distribution. > > Given the low number of users of plplot on Slackware I don't believe your > plan should be changed as a result of the above information, especially > since there is a viable workaround. I mention it only for completeness so > people are aware of the possible impact and the steps needed to circumvent > it. Hi Jonathan: Thanks for this information about the current lack of Qt5 on official Slackware. My gut feeling is Qt4 has become dated and Qt5 is its worthy successor. Therefore, I would be surprised if this lack of Qt5 on Slackware persists much longer, i.e., I think it is likely you will get your wish sooner rather than later. But if that doesn't happen for some reason, PLplot-5.18.0 would still be usable on official Slackware if a user decided not to use the workaround you mentioned above. Of course, Qt-related components of PLplot such as the devices provided by our "qt" device driver would be automatically dropped by our build system when it did not find Qt5, but other excellent choices for devices such as those provided by our "cairo" device driver would still be available (assuming our build system finds on Slackware the Pango and Cairo libraries upon which our "cairo" device driver depends). By the way, Slackware was my very first Linux distribution (in 1996 on a pentium-133). Happy days! 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 __________________________ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X