RE : [guidata/guiqwt] Re: pure python qwt

[Pierre Raybaut]

To be even more exact, the copies contain acceptable license terms/copyrights since v6.1.2a5 (available on PyPI until now) but v6.1.2a7 contains the very last license terms/copyrights (and is now available on PyPI).

However, more important than the license terms, please do remember that it’s an alpha release, so it’s still experimental and unfinished. So it’s too early to begin a big migration from PyQwt to python-qwt, *but* now is the time to begin testing it with your own code so that python-qwt may be ready even sooner in a beta state for more extensive tests.


De : Pierre Raybaut
Envoyé le :samedi 29 août 2015 23:13
À : ***@googlegroups.com
Objet :RE: [guidata/guiqwt] Re: pure python qwt


Uwe, I'm sure they will *not* be interested in more details 😊. And I'm sure that we will come to an agreement very soon: we are doing things so much more challenging every day.

And by the way, python-qwt v6.1.2a6, available on PyPI is at the same state as GitHub. So it doesn't have to be removed...! This is already the "official update" (it it does mean something: this is still an alpha release).

All old copies with the license issue/missing copyrights are not available for a while now.

De : Uwe Rathmann
Envoyé : ‎29/‎08/‎2015 17:57
À : ***@googlegroups.com
Objet : [guidata/guiqwt] Re: pure python qwt

- do you consider qwt ready for use by 3rd parties?

Definitely not: all packages released so far are ignoring copyrights and
license implications !

If you are interested in more details see:

[1] https://github.com/PierreRaybaut/python-qwt/issues/11
[2] https://github.com/PierreRaybaut/python-qwt/issues/13
[3] https://github.com/PierreRaybaut/python-qwt/issues/14
[4] https://github.com/PierreRaybaut/python-qwt/issues/15

I'm happy to say that we made substantially progress, but I need more
time before I'm giving a final o.k. to it.

So please remove all copies ( including python-qwt 6.1.2a6 from https://
pypi.python.org/pypi/python-qwt ! ) and take care of not propagating it
even further. Instead use the current state from https://github.com/
PierreRaybaut/python-qwt or wait for an official update from Pierre.

According to the license:

The project - status today - is a mixture of MIT licensed and Qwt
licensed files - examples are under the PyQwt license. You have to find
out yourself, what this means for using it in your application.

Uwe

 
--
You received this message because you are subscribed to the Google Groups "guidata/guiqwt" group.
To unsubscribe from this group and stop receiving emails from it, send an email to guidata_guiqwt+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "guidata/guiqwt" group.
To unsubscribe from this group and stop receiving emails from it, send an email to guidata_guiqwt+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Carlos Pascual]

Hi Pierre and Uwe,

Thanks a lot for your replies. I definitely am interested in the
licensing issues and relieved to see that there seems to be good
progress in solving them in spite of the difficult beginnings ;)
Errors done in "good-faith" may be annoying but should not matter in the
long term (specially among FOSS developers).

Now, assuming that the licensing issues will be overcome and once Pierre
catches his breath, I would still be interested in knowing about the
development model and performance (see my original questions).

Thanks again to both Uwe and Pierre for your replies and for sharing
your respective works.

Carlos

Post by Pierre Raybaut
To be even more exact, the copies contain acceptable license
terms/copyrights since v6.1.2a5 (available on PyPI until now) but
v6.1.2a7 contains the very last license terms/copyrights (and is now
available on PyPI).
However, more important than the license terms, please do remember
that it’s an alpha release, so it’s still experimental and
unfinished. So it’s too early to begin a big migration from PyQwt to
python-qwt, *but* now is the time to begin testing it with your own
code so that python-qwt may be ready even sooner in a beta state for
more extensive tests.
De : Pierre Raybaut
Envoyé le :samedi 29 août 2015 23:13
Objet :RE: [guidata/guiqwt] Re: pure python qwt
Uwe, I'm sure they will *not* be interested in more details 😊. And
I'm sure that we will come to an agreement very soon: we are doing
things so much more challenging every day.
And by the way, python-qwt v6.1.2a6, available on PyPI is at the same
state as GitHub. So it doesn't have to be removed...! This is already
the "official update" (it it does mean something: this is still an
alpha release).
All old copies with the license issue/missing copyrights are not available for a while now.
De : Uwe Rathmann
Envoyé : ‎29/‎08/‎2015 17:57
Objet : [guidata/guiqwt] Re: pure python qwt

- do you consider qwt ready for use by 3rd parties?

Definitely not: all packages released so far are ignoring copyrights
and license implications !
[1] https://github.com/PierreRaybaut/python-qwt/issues/11
[2] https://github.com/PierreRaybaut/python-qwt/issues/13
[3] https://github.com/PierreRaybaut/python-qwt/issues/14
[4] https://github.com/PierreRaybaut/python-qwt/issues/15
I'm happy to say that we made substantially progress, but I need more
time before I'm giving a final o.k. to it.
So please remove all copies ( including python-qwt 6.1.2a6 from
https:// pypi.python.org/pypi/python-qwt ! ) and take care of not
propagating it even further. Instead use the current state from
https://github.com/ PierreRaybaut/python-qwt or wait for an official
update from Pierre.
The project - status today - is a mixture of MIT licensed and Qwt
licensed files - examples are under the PyQwt license. You have to
find out yourself, what this means for using it in your application.
Uwe

--
+----------------------------------------------------+
Carlos Pascual Izarra
Scientific Software Coordinator
Computing Division
ALBA Synchrotron [http://www.albasynchrotron.es]
Carretera BP 1413 de Cerdanyola-Sant Cugat, Km. 3.3
E-08290 Cerdanyola del Valles (Barcelona), Spain
E-mail: ***@cells.es
Phone: [phone]
+----------------------------------------------------+

[Pierre Raybaut]

Hi Carlos, Uwe and others,

Personally,
I wouldn’t jump to conclusions at this stage of the “python-qwt” project.

So here is
my unbiased view on the situation: I’m not attached to either “Qwt” or
“python-qwt”; my only interest is to find the best solution for the future of
our data processing software development.



Let’s start
from the beginning. A lot of applications (here and there) are based on
“guiqwt” which relies on PyQwt. PyQwt was the best choice in 2008 (when the “guidata”
and “guiqwt” projects started) for plotting data efficiently. Since 2010, we
know that there is a “PyQwt obsolescence” issue that we must solve in order to maintain
our data processing software collection. In 2011, I started looking for an
alternative to PyQwt. But then I was forced to step back from intensive
software development at my work (I still am), so nothing happened except when I found some
time to spare on this during my vacations (I started “python-qwt” at home
during Christmas 2013).

I came
rapidly to the conclusion that there were two solutions:

1. Write a
pure Python version of Qwt – that’s “python-qwt” – which implements only the
interesting part of the API (basically only the canvas and axes) ; “guiqwt” can
already take care of image visualization very efficiently thanks to its C++
scaler engine.

2. Rely on
an OpenGL-based solution (the best candidate seems to be “vispy”) and rewrite the intermediate layer of
“guiqwt” which is currently interfaced with a Qwt-like API.



So,
currently, with “python-qwt”, I’m exploring solution 1. which is clearly less
performant than “PyQwt”. As Uwe pointed out, performance is a relative matter:
the idea is to find out if the performance loss is acceptable for our
applications. When executing “guiqwt” examples on a Core i5-2520M @ 2.50GHz,
performance loss can be imperceptible (depending on the compiler used to build
extensions ; there are still things to clear out of course). However, we still
have to optimize “python-qwt” and evaluate it with our applications to really
know if we are going to adopt this project for our future developments. I hope
that we will be able to know if this is the solution before the end of the
year.



If solution
1. does not fit our needs, we will switch to solution 2.

The plan is
to be able to transform “guiqwt-2.3” into “guiqwt-2.4” (python-qwt) or to “guiplot”
(vispy) before the end of 2016.



Independently
from guidata/guiqwt, I think the “python-qwt” project may be of interest (even
if we finally decide to switch to vispy for “guiqwt”). That’s why I wanted to
make it public, so that people could benefit from this work and eventually use
it to replace PyQwt in their own project if it fits their need.



Some answers
@Uwe:



“This
project is a port of some subset of the Qwt C++ project ( 56000 vs 12000 lines
of code ! )”

Comparing
the line of codes of a Python project with a C++ project has its limits (Python
is leading to more compact code). A part from that, “python-qwt” does not
implement the whole Qwt API, indeed. That’s because we don’t need it: “guiqwt”
is providing the rest.



“Almost all
projects ( even the lamest duck ) claims to be "high performant" and
I wouldn't trust on any statement like this.”

Performance
is a relative matter, I agree. We never stated that “guiqwt” was highly
performant in absolute terms. We only wrote that it was more performant than “matplotlib”,
which is undoubtedly true.



“a) Line
plots” – “python-qwt can't compete with a pyqt running the X11 paint engine -
because of being Qt5”

FYI, “python-qwt” is compatible with both Qt4 and Qt5. So, users can choose to use Qt4 if it's really necessary.




“b) Raster
data”

“python-qwt
does not support displaying of raster data at all at the moment”

As I wrote
above, “python-qwt” does need to do support this feature because “guiqwt” is already
supporting it and it proved to be a major asset (image visualization is very powerful within
“guiqwt” thanks to the included C++ scaler engine – for example, an application of ours is
showing and processing in real-time 20,000 x 20,000 pixel images: scaling,
changing contrast, and applying any affine transform to the image in real-time –
that is: we move a cursor to adjust a parameter and the image is refreshing
real-time).



“c) Polygon
clipping”

“From the
announcement it looks like python-qwt dropped the polygon clipping [
]In
situations, where the scale ranges are small compared to the bounding rectangle
of the curve a python-qwt application will probably show a quite lousy
performance in other situations you won't see any difference.”

You’re
perfectly right: this fits the warning you may read in “python-qwt” README. I
think that polygon clipping is not necessary for our (internal) applications
using “guiqwt”, so it doesn’t bother me but other users should indeed be aware
of this limitation, in a very particular case. Maybe it could be implemented in
the future, but right now I don’t see how to do it without a significant loss
of performance.



Regarding
the project future, Uwe is right to state that we have two options:

“a) No own
development and waiting for the next C++ version

b)
Branching with the problem of becoming outdated”



For now, I
think that waiting for the next C++ version is not a good idea. Porting code
from C++ to Python was not so easy and there is still a lot of work to do to optimize
things. The next step could be to optimize code deeper than I did: you have
to be smarter in Python than in C++ because milliseconds are easily lost if the
algorithm is not efficient enough or if the data structure is too complicated
and convulated. So the code base could evolve separately from its C++
counterpart.

Anyway, the
Qwt API that we work with is so basic that I don’t imagine that the future
evolutions would be hard to follow even if the code base has evolved since
then.

So ==>
option b).


Carlos, I hope that this message anwers you questions!

Cheers,
-Pierre

Subject: [guidata/guiqwt] Re: pure python qwt
Date: Mon, 31 Aug 2015 09:11:05 +0000

Post by Carlos Pascual
development model

This project is a port of some subset of the Qwt C++ project ( 56000 vs
12000 lines of code ! )
From now on their might only be 2 options how to continue.
a) No own development and waiting for the next C++ version
b) Branching with the problem of becoming outdated

Post by Carlos Pascual
performance

Almost all projects ( even the lamest duck ) claims to be "high
performant" and I wouldn't trust on any statement like this.
"Performance" always depends on the very specific use case, what usually
also includes application code. IMHO the only reasonable thing is trying
to understand what happens in which situation.
a) Line plots
With Qt5 the X11 paint engine is gone - instead the plot is rendered by
the raster paint engine before passing it to X11. Consequence is that
hardware acceleration is also gone with Qt5 ( I'm working on an OpenGL
canvas for Qwt 6.2, but unfortunately the Qt OpenGL paint engine doesn't
have that quality ).
Now it matters how important hardware acceleration is for you. For raster
graphics it isn't, for vector graphics ( f.e curves ) the difference is
significant.
But what means "significant": for a static plot of ~1000 points probably
not that much, for an application, that wants to replot in high refresh
rates a lot.
But at least one thing can be said in general: for line plots python-qwt
can't compete with a pyqt running the X11 paint engine - because of being
Qt5.
b) Raster data
Rendering an image that is displayed on screen is composed by requesting
values at any position from the application one by one. So f.e it is
possible to calculate those values on the fly when being requested
without having any memory footprint at all.
But of course you could also load gigs of values from disk into memory
and finding the value by interpolation algos.
So an answer about the Qwt memory footprint for displaying raster data as
image can't be given, as this all is decided in application code.
But as far as I can see python-qwt does not support displaying of raster
data at all at the moment.
c) Polygon clipping
Qt is known for doing clipping too late, with the consequence of having
potential performance issues. That's why Qwt does polygon clipping before
entering QPainter.
From the announcement it looks like python-qwt dropped the polygon
clipping. If this becomes a major performance issue depends on the
coordinates of the points and the current ranges of scales.
In situations, where the scale ranges are small compared to the bounding
rectangle of the curve a python-qwt application will probably show a
quite lousy performance in other situations you won't see any difference.
Uwe
--
You received this message because you are subscribed to the Google Groups "guidata/guiqwt" group.
For more options, visit https://groups.google.com/d/optout.

[Carlos Pascual]

Again thanks you both for your replies,

My questions about performance are pretty well answered now.

Also Pierre's intentions for the future of python-qwt are much clearer
for us now.

Just one more question/clarification about the "Solution 2" scenario:

Suppose that we (in Taurus) decided to use only guiqwt for our plotting
(i.e. we stop importing PyQt4.Qwt in our code and import guiqwt only).
Now suppose that you come to the conclusion that python-qwt is not good
enough and you move to vispy. Would that mean that our widgets would
need to be adapted? or would the qwt->vispy transition be done inside
guiqwt maintaining API compatibility?

Cheers,

Carlos

Post by Pierre Raybaut
Hi Carlos, Uwe and others,
Personally,
I wouldn’t jump to conclusions at this stage of the “python-qwt”
project.
So here is
my unbiased view on the situation: I’m not attached to either “Qwt” or
“python-qwt”; my only interest is to find the best solution for the
future of our data processing software development.
Let’s start
from the beginning. A lot of applications (here and there) are based
on “guiqwt” which relies on PyQwt. PyQwt was the best choice in 2008
(when the “guidata” and “guiqwt” projects started) for plotting data
efficiently. Since 2010, we know that there is a “PyQwt obsolescence”
issue that we must solve in order to maintain our data processing
software collection. In 2011, I started looking for an alternative to
PyQwt. But then I was forced to step back from intensive software
development at my work (I still am), so nothing happened except when
I found some time to spare on this during my vacations (I started
“python-qwt” at home during Christmas 2013).
I came
1. Write a
pure Python version of Qwt – that’s “python-qwt” – which implements
only the interesting part of the API (basically only the canvas and
axes) ; “guiqwt” can already take care of image visualization very
efficiently thanks to its C++ scaler engine.
2. Rely on
an OpenGL-based solution (the best candidate seems to be “vispy”) and
rewrite the intermediate layer of “guiqwt” which is currently
interfaced with a Qwt-like API.
So,
currently, with “python-qwt”, I’m exploring solution 1. which is
clearly less performant than “PyQwt”. As Uwe pointed out, performance
is a relative matter: the idea is to find out if the performance loss
is acceptable for our applications. When executing “guiqwt” examples
(depending on the compiler used to build extensions ; there are still
things to clear out of course). However, we still have to optimize
“python-qwt” and evaluate it with our applications to really know if
we are going to adopt this project for our future developments. I
hope that we will be able to know if this is the solution before the
end of the year.
If solution
1. does not fit our needs, we will switch to solution 2.
The plan is
to be able to transform “guiqwt-2.3” into “guiqwt-2.4” (python-qwt) or
to “guiplot” (vispy) before the end of 2016.
Independently
from guidata/guiqwt, I think the “python-qwt” project may be of
interest (even if we finally decide to switch to vispy for “guiqwt”).
That’s why I wanted to make it public, so that people could benefit
from this work and eventually use it to replace PyQwt in their own
project if it fits their need.
Some answers
“This
project is a port of some subset of the Qwt C++ project ( 56000 vs
12000 lines of code ! )”
Comparing
the line of codes of a Python project with a C++ project has its
limits (Python is leading to more compact code). A part from that,
“python-qwt” does not implement the whole Qwt API, indeed. That’s
because we don’t need it: “guiqwt” is providing the rest.
“Almost all
projects ( even the lamest duck ) claims to be "high performant" and
I wouldn't trust on any statement like this.”
Performance
is a relative matter, I agree. We never stated that “guiqwt” was
highly performant in absolute terms. We only wrote that it was more
performant than “matplotlib”, which is undoubtedly true.
“a) Line
plots” – “python-qwt can't compete with a pyqt running the X11 paint
engine - because of being Qt5”
FYI, “python-qwt” is compatible with both Qt4 and Qt5. So, users can
choose to use Qt4 if it's really necessary.
“b) Raster
data”
“python-qwt
does not support displaying of raster data at all at the moment”
above, “python-qwt” does need to do support this feature because
“guiqwt” is already supporting it and it proved to be a major asset
(image visualization is very powerful within “guiqwt” thanks to the
included C++ scaler engine – for example, an application of ours is
scaling, changing contrast, and applying any affine transform to the
image in real-time – that is: we move a cursor to adjust a parameter
and the image is refreshing real-time).
“c) Polygon
clipping”
“From the
announcement it looks like python-qwt dropped the polygon clipping
[…]In situations, where the scale ranges are small compared to the
bounding rectangle of the curve a python-qwt application will
probably show a quite lousy performance in other situations you won't
see any difference.”
You’re
perfectly right: this fits the warning you may read in “python-qwt”
README. I think that polygon clipping is not necessary for our
(internal) applications using “guiqwt”, so it doesn’t bother me but
other users should indeed be aware of this limitation, in a very
particular case. Maybe it could be implemented in the future, but
right now I don’t see how to do it without a significant loss of
performance.
Regarding
“a) No own
development and waiting for the next C++ version
b)
Branching with the problem of becoming outdated”
For now, I
think that waiting for the next C++ version is not a good idea.
Porting code from C++ to Python was not so easy and there is still a
lot of work to do to optimize things. The next step could be to
optimize code deeper than I did: you have to be smarter in Python
than in C++ because milliseconds are easily lost if the algorithm is
not efficient enough or if the data structure is too complicated and
convulated. So the code base could evolve separately from its C++
counterpart.
Anyway, the
Qwt API that we work with is so basic that I don’t imagine that the
future evolutions would be hard to follow even if the code base has
evolved since then.
So ==>
option b).
Carlos, I hope that this message anwers you questions!
Cheers,
-Pierre

Subject: [guidata/guiqwt] Re: pure python qwt
Date: Mon, 31 Aug 2015 09:11:05 +0000

Post by Carlos Pascual
development model

This project is a port of some subset of the Qwt C++ project ( 56000
vs 12000 lines of code ! )
From now on their might only be 2 options how to continue.
a) No own development and waiting for the next C++ version
b) Branching with the problem of becoming outdated

Post by Carlos Pascual
performance

Almost all projects ( even the lamest duck ) claims to be "high
performant" and I wouldn't trust on any statement like this.
"Performance" always depends on the very specific use case, what
usually also includes application code. IMHO the only reasonable
thing is trying to understand what happens in which situation.
a) Line plots
With Qt5 the X11 paint engine is gone - instead the plot is rendered
by the raster paint engine before passing it to X11. Consequence is
that hardware acceleration is also gone with Qt5 ( I'm working on
an OpenGL canvas for Qwt 6.2, but unfortunately the Qt OpenGL paint
engine doesn't have that quality ).
Now it matters how important hardware acceleration is for you. For
raster graphics it isn't, for vector graphics ( f.e curves ) the
difference is significant.
But what means "significant": for a static plot of ~1000 points
probably not that much, for an application, that wants to replot in
high refresh rates a lot.
But at least one thing can be said in general: for line plots
python-qwt can't compete with a pyqt running the X11 paint engine -
because of being Qt5.
b) Raster data
Rendering an image that is displayed on screen is composed by
requesting values at any position from the application one by one.
So f.e it is possible to calculate those values on the fly when
being requested without having any memory footprint at all.
But of course you could also load gigs of values from disk into
memory and finding the value by interpolation algos.
So an answer about the Qwt memory footprint for displaying raster
data as image can't be given, as this all is decided in application
code.
But as far as I can see python-qwt does not support displaying of
raster data at all at the moment.
c) Polygon clipping
Qt is known for doing clipping too late, with the consequence of
having potential performance issues. That's why Qwt does polygon
clipping before entering QPainter.
From the announcement it looks like python-qwt dropped the polygon
clipping. If this becomes a major performance issue depends on the
coordinates of the points and the current ranges of scales.
In situations, where the scale ranges are small compared to the
bounding rectangle of the curve a python-qwt application will
probably show a quite lousy performance in other situations you
won't see any difference.
Uwe

--
+----------------------------------------------------+
Carlos Pascual Izarra
Scientific Software Coordinator
Computing Division
ALBA Synchrotron [http://www.albasynchrotron.es]
Carretera BP 1413 de Cerdanyola-Sant Cugat, Km. 3.3
E-08290 Cerdanyola del Valles (Barcelona), Spain
E-mail: ***@cells.es
Phone: [phone]
+----------------------------------------------------+

[Pierre Raybaut]

Post by Carlos Pascual
Suppose that we (in Taurus) decided to use only guiqwt for our plotting
(i.e. we stop importing PyQt4.Qwt in our code and import guiqwt only).
Now suppose that you come to the conclusion that python-qwt is not good
enough and you move to vispy. Would that mean that our widgets would
need to be adapted? or would the qwt->vispy transition be done inside
guiqwt maintaining API compatibility?

If we switch to vispy, even if we will try to keep the guiqwt API almost identical for the end user, I'm sure that there will be consequences for your widgets. But we will have to migrate our own applications, with the same kind of compatibility issues, so there is no doubt that we will try to keep those changes to the strict minimum and that documentation will be available on how to migrate from guiqwt (based on PyQwt) to guiplot (based on vispy).

Independantly from this migration, know that PyQt.Qwt5 is never imported in our applications: we are exclusively relying on guiqwt and you should do the same (it will help you migrate your widgets for both solutions: python-qwt or vispy).

[Pierre Raybaut]

Uwe,

guiqwt is focusing on visualization (adjusting the levels histogram, rotating or rescaling images are basic visualization features), not data processing like our internal software based on guiqwt. The image display engine of guiqwt is quite optimized: no memory copy at all is done on the displayed data, so unless doing memory mapping I don't see how to get a smaller memory footprint. Anyway, there was nothing like it in PyQwt5 at least. As for Qwt6, I can't tell because I don't know. Similarly, you should try it instead of blindly and systematically depreciating it.

Other plotting items are not supported just because we don't need them in guiqwt, that's all. I'm thrilled to learn that their were introduced in Qwt 3, 4 or 5, but, after all, you are posting on the guidata/guiqwt discussion group. 😊
I'll eventually clarify python-qwt README, in case someone is really interested in those other items. But please remember that a coding project is a living thing: maybe someone *constructive* will contribute by implementing those items.

Cheers,
Pierre
________________________________
De : Uwe Rathmann<mailto:***@tigertal.de>
Envoyé : ‎31/‎08/‎2015 21:36
À : ***@googlegroups.com<mailto:***@googlegroups.com>
Objet : [guidata/guiqwt] Re: pure python qwt

Hi Pierre,

[ image processing ... ]

Comparing qwt and guiqwt here is somehow pointless as qwt doesn't have
any image processing at all. What Qwt has is a plot item that creates
images from 3D data ( z values -> color ).

The Qwt approach means, that algos are running on the data in application
code - not on images in libarary code, what has pros and cons. But when
the user has the most common use case of fast rendering with a low memory
footprint from 3D data only I would be surprised if guiqwt can do it
better.

There are also many details to take care of. F.e the coordinate system is
not necessarily equidistant due to the fact of rounding errors, when
drawing to a integer based coordinate system ( widgets ). When rendering
images you always need to take care of misalignments between other plot
items like points or grid lines.

But in the end it's like with, what I wrote about "performance": it
always depends and it is often difficult to compare. But even if we both
would try, we would fail as we both know enough about the other
implementation and which specific issues are solved there.

python-qwt” does not implement the whole Qwt API, indeed ...

Dropping the slider/dials/wheels widgets and to focus on the classes of
the plot framework makes a reasonable subset, but when python-qwt not
even intends to cover a majority of the plot items I'm not sure if it is
a good idea to call it "python-qwt".

The README is wrong that explicitly states being a complete port beside
of 5 classes dealing with zooming. If you don't intend to have a port of
all the missing classes I suggest to make this clearer - you are creating
wrong expections otherwise.( See f.e https://ftp-master.debian.org/new/
python-qwt_6.1.2~a7-1~exp1.html )

... that’s because we don’t need it: “guiqwt” is providing the rest.

guiqwt focuses on specific use cases and adds extra value there, but the
reason, why so many classes have not been ported, is simply because guiqwt
doesn't need it.

It would be better to summarize, that you like to offer the plot widget,
the renderer to create PDF documents and a limited subset of plot items
( only 3 out of 16 ! ):

- QwtPlotCurve
- QwtPlotMarker
- QwtPlotHistogram

But featurewise this subset is on a level of what Qwt 2 offered - far
behind Qwt 5, what is currently supported by PyQwt.

ciao,
Uwe






--
You received this message because you are subscribed to the Google Groups "guidata/guiqwt" group.
To unsubscribe from this group and stop receiving emails from it, send an email to guidata_guiqwt+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Carlos Pascual]

C'mon guys!

I think that you both are actually giving pretty useful information in
this thread (do an exercise: re-read it just filtering out the uncalled
provocations and hostile remarks and you will see that it turns out to
be useful, informative and constructive) :)

With this I am just trying to say:

i) thanks Uwe and Pierre for your answers

ii) please do not let the anger ruin what could be a fruitful relation
for everybody. If python-qwt succeeds, Pierre can get contributors; Uwe
retains people from the python world around Qwt; and us -former PyQwt5
users- get an easier path of update.

Now, just to give you a hint of which aspects of this thread can be
interesting for some users such as me, here is an example on the kind of
decision that the Taurus community is facing:

a) re-writing all our plotting widgets from scratch (e.g. using
pyqtgraph, or vispy, or PyMca)

b) contribute to python-qwt so that our already-existing PyQwt5-based
widgets can use it (we would need to implement zooms and scales among
other things)

c) ditch our PyQwt5-based widgets and focus the effort on our also-
existing-but-less-mature guiqwt-based widgets (so that we do not care
about the missing parts in python-qwt because guiqwt provides them)

Option a) was the only one available to us two weeks ago. It is
expensive but it opens new interesting possibilities (mostly for 3D
visualization). Options b) and c) both seem to simplify the transition.
Their relative merits depend on how much work we need put on each one,
and on the level of support we can expect (by author and/or potential
community) and on the perceived long-term viability of python-qwt and
guiqwt compared to the alternatives in a).

I hope and wish that this post contributes to smooth things out a little
bit...

Cheers and thanks again...

Carlos

Post by Pierre Raybaut
Hi Pierre,

Post by Pierre Raybaut
Other plotting items are not supported just because we don't need
them in guiqwt, that's all. I'm thrilled to learn that their were
introduced in Qwt 3, 4 or 5, but, after all, you are posting on the
guidata/guiqwt discussion group. 😊

Well, this thread is about comparing PyQwt against your Qwt python
port and Carlos was interested in "how to get rid of our dependency
on pyqwt5" in *his* application.
I consider comparing features is somehow interesting in this context
and as I had checked the code already ...
There is also an aspect of your port, that might be interesting for
closed source applications: a GPL based element in the license stack
is gone.
But anyway, guess now I have given all I can contribute.
ciao,
Uwe

--
+----------------------------------------------------+
Carlos Pascual Izarra
Scientific Software Coordinator
Computing Division
ALBA Synchrotron [http://www.albasynchrotron.es]
Carretera BP 1413 de Cerdanyola-Sant Cugat, Km. 3.3
E-08290 Cerdanyola del Valles (Barcelona), Spain
E-mail: ***@cells.es
Phone: [phone]
+----------------------------------------------------+

[Pierre Raybaut]

Hi Carlos,

PythonQwt <http://pierreraybaut.github.io/PythonQwt/>is making progress:
it's stabilizing (documentation has been added
<http://pythonhosted.org/PythonQwt/>). In the next few weeks, I'll try to
test our most critical application in terms of performance (it allows
manipulating images of 20 000 x 20 000 pixels: zooming in and out smoothly
by moving the mouse with right-click button pressed, changing contrast in
real-time using guiqwt's contrast panel, etc.). This will be the most
important test and will eventually validate the approach of PythonQwt.

Regarding the choice between b) and c), it clearly depends on your code
(taurus) and what will be missing exactly in PythonQwt. Our own strategy is
to invest in guiqwt for the high-level features and leave the basic
plotting features to PythonQwt (the base plot widget, the scales, the grid,
and so on). In time, this strategy could allow us to switch to another
plotting library more easily.

-Pierre

Post by Carlos Pascual
Now, just to give you a hint of which aspects of this thread can be
interesting for some users such as me, here is an example on the kind of
a) re-writing all our plotting widgets from scratch (e.g. using
pyqtgraph, or vispy, or PyMca)
b) contribute to python-qwt so that our already-existing PyQwt5-based
widgets can use it (we would need to implement zooms and scales among
other things)
c) ditch our PyQwt5-based widgets and focus the effort on our also-
existing-but-less-mature guiqwt-based widgets (so that we do not care
about the missing parts in python-qwt because guiqwt provides them)
Option a) was the only one available to us two weeks ago. It is
expensive but it opens new interesting possibilities (mostly for 3D
visualization). Options b) and c) both seem to simplify the transition.
Their relative merits depend on how much work we need put on each one,
and on the level of support we can expect (by author and/or potential
community) and on the perceived long-term viability of python-qwt and
guiqwt compared to the alternatives in a).
I hope and wish that this post contributes to smooth things out a little
bit...
Cheers and thanks again...
Carlos

Post by Pierre Raybaut
Hi Pierre,

Post by Pierre Raybaut
Other plotting items are not supported just because we don't need
them in guiqwt, that's all. I'm thrilled to learn that their were
introduced in Qwt 3, 4 or 5, but, after all, you are posting on the
guidata/guiqwt discussion group. 😊

Well, this thread is about comparing PyQwt against your Qwt python
port and Carlos was interested in "how to get rid of our dependency
on pyqwt5" in *his* application.
I consider comparing features is somehow interesting in this context
and as I had checked the code already ...
There is also an aspect of your port, that might be interesting for
closed source applications: a GPL based element in the license stack
is gone.
But anyway, guess now I have given all I can contribute.
ciao,
Uwe

--
+----------------------------------------------------+
Carlos Pascual Izarra
Scientific Software Coordinator
Computing Division
ALBA Synchrotron [http://www.albasynchrotron.es]
Carretera BP 1413 de Cerdanyola-Sant Cugat, Km. 3.3
E-08290 Cerdanyola del Valles (Barcelona), Spain
Phone: [phone]
+----------------------------------------------------+