Qwt 6 backwards compatibility with Qwt 5
The advent of Qwt 6 which replaces Qwt 5 without providing full backwards compatibility has caused me some consternation about the merits of moving to the new version. The existing classes that I have implemented that use Qwt depend on the old data model based on the QwtData class. Because QwtData is not provided with Qwt 6 these classes would need to be revised, perhaps significantly.
So, the first question is: Are there Qwt users who have made the transition from version 5 to version 6 and would be willing to share their experience vis a vis the relative merits of the two versions as a basis for helping others to decide if they should stay with Qwt 5 or move to Qwt 6?
Also: Is there any porting guidance that users experienced with the version change impacts on end user code would be willing to share?
I can offer a minor Qwt 5 to Qwt 6 Patch Kit that incorporates support for the QwtData class from Qwt 5 into the Qwt 6 library. I have used this to successfully adapt classes using Qwt 5 QwtData, QwtPlotItem, and QwtPlotPicker base classes to build and execute correctly against the Qwt 6 release. Though this Patch Kit is almost certainly not a complete backwards compatibility solution it may be useful to others who have a similar need. I'll send the Patch Kit on request.
Re: Qwt 6 backwards compatibility with Qwt 5
Quote:
Originally Posted by
bcastalia
The advent of Qwt 6 which replaces Qwt 5 without providing full backwards compatibility has caused me some consternation about the merits of moving to the new version. The existing classes that I have implemented that use Qwt depend on the old data model based on the QwtData class. Because QwtData is not provided with Qwt 6 these classes would need to be revised, perhaps significantly.
Instead of QwtData you have QwtSeriesData<QPointF> - the API is more or less equivalent. Renaming a couple of methods is trivial and absolutely no reason for any consternation.
Much more substantial is that the render engine has been moved from ints to doubles. In the end this is a delayed Qt3 -> Qt4 port, but I can't support Qt3 forever.
Uwe
PS1: when moving to a new version I recommend to port to Qwt from SVN trunk ( or to wait until there is an official release - planned after Qt5 is available ).
PS2: and yes the scene graph of Qt5 means again changing APIs sooner or later significantly ( coming with Qwt 7.x )
Re: Qwt 6 backwards compatibility with Qwt 5
Quote:
Originally Posted by
Uwe
Instead of QwtData you have QwtSeriesData<QPointF> - the API is more or less equivalent. Renaming a couple of methods is trivial and absolutely no reason for any consternation.
The APIs of Qwt 5 and Qwt 6 are rather less than "equivalent". Equivalence would provide backwards compatibility. Some documentation providing guidance, with specifics, for end users on making the transitiion would certainly be helpful. As it is, I do not find what is involved as trivial as renaming a couple of methods. The challenge is that there is a substantial difference in the data model. Of course, the changes might seem trivial from the perspective of the Qwt developer, but the perspective from outside presents what appears to be a Monty Python ("And now for something completely different!").
If the API changes are so trivial, then it seems that providing backwards compatibility to Qwt 5 in the Qwt 6 release would be trivial for the developer. I was able to implement a patch that provides partial, at least, backwards compatibility - but certainly not API equivalence - into the Qwt 6 library. The patch implementation was not trivial; the use of the Patch Kit, along with the Notes that I have provided, should be trivial for users in a similiar situation to what I faced. Perhaps the Patch Kit might suggest how full backwards compatibility (continued Qt 3 support notwithstanding) could be provided by Qwt developers.
Quote:
Originally Posted by
Uwe
Much more substantial is that the render engine has been moved from ints to doubles. In the end this is a delayed Qt3 -> Qt4 port, but I can't support Qt3 forever.
The Qt 3 to Qt 4 porting is a separate issue, in my case, though I can understand that this may affect others.
What effects do you expect the use of doubles instead of ints to have? The latter occupy less space and are executed faster, but perhaps the nature of the algorithms involved would result in overall faster excecution with doubles. Clarifying this point could be interesting.
Quote:
Originally Posted by
Uwe
PS1: when moving to a new version I recommend to port to Qwt from SVN trunk ( or to wait until there is an official release - planned after Qt5 is available ).
PS2: and yes the scene graph of Qt5 means again changing APIs sooner or later significantly ( coming with Qwt 7.x )
I am using the Qwt SVN trunk code source for the 6.0.2 implementation. The Patch Kit was applied to this version.
I am not eager to rush to Qt 5, and am not convinced from what I have read of the changes that it would be of benefit to the applications I develop. At this point I am also not seeing the benefits for my work of moving to Qwt 6. If I am going to cross this Rubicon I need to know that it's worth the effort - and there is no doubt that effort is involved for revising the existing Qwt 5 based code, as well as clambering up the learning curve for the new API - to comit to Qwt 6; especially when yet another significant (and, I assume, also not backwards compatible) API change is coming with Qwt 7.
It sounds like it's best for me to wait and see ....
Re: Qwt 6 backwards compatibility with Qwt 5
Quote:
The challenge is that there is a substantial difference in the data model.
The modification is about introducing templates, so that the code assigning samples and iterating over them doesn't need to be duplicated for other plot items than curves. This was more or less a preparation for all the new stuff ( probably most new features of any Qwt release ) you find in SVN trunk ( = 6.1 ).
But are we really talking about the same:
QwtData/Qwt5:
- virtual size_t size() const
- virtual double x(size_t i) const;
- virtual double y(size_t i) const ;
QwtSeriesData<QPointF>/Qwt6:
- virtual size_t size() const;
- virtual QPointF sample( size_t i ) const;
Quote:
What effects do you expect the use of doubles instead of ints to have?
On screen none ( maybe later on high resolution screens on the Mac with Qt 5 ) - it is all about QwtPlotRenderer.
F.e. when rendering to a scalable vector format ( PDF, SVG ) you simply need to have doubles.
Quote:
I am not eager to rush to Qt 5, and am not convinced from what I have read ...
So what - do you expect me to sell you something ?
Uwe
PS1: Qwt 6.1 is planned to be released end of this year, Qwt 7 is not more than an idea yet
Re: Qwt 6 backwards compatibility with Qwt 5
Quote:
Originally Posted by
Uwe
PS1: when moving to a new version I recommend to port to Qwt from SVN trunk ( or to wait until there is an official release - planned after Qt5 is available ).
I see that Qt 5 was released on the 19th December, which was a nice Christmas present. What sort of timescales do you have in mind before Qwt 6 supports it?
Thanks in advance,
Mark
Re: Qwt 6 backwards compatibility with Qwt 5
Quote:
Originally Posted by
liversedge
What sort of timescales do you have in mind before Qwt 6 supports it?
You will see the first release candidate of Qwt 6.1 next week.
Uwe
