RE : [guidata/guiqwt] Re: pure python qwt
Pierre Raybaut
Edit : So far, testing is very promising. Our most demanding application in terms of performance is running very smoothly with guiqwt v3 based on PythonQwt. This is great news.
Regarding your plan b), it could be interesting to write a list of Qwt classes your widgets depend on.
De : Pierre Raybaut
Envoyé le :jeudi 8 octobre 2015 09:41
À : guidata/guiqwt
Objet :Re: [guidata/guiqwt] Re: pure python qwt
Hi Carlos,
PythonQwt is making progress: it's stabilizing (documentation has been added). 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
Le mardi 1 septembre 2015 19:11:40 UTC+2, Carlos Pascual a écrit :
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
On Tue 1 September 2015 10:00:01 Uwe Rathmann wrote:
> Hi Pierre,
>
> > 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: cpas...@cells.es
Phone: +34 93 592 4428
+----------------------------------------------------+
--
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_guiqw...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Carlos Pascual
Thanks for the update.
Regarding the class list: I cannot do an exhaustive one right now, but
from memory, I would say that pickers and zoomers are the main ones
Pierre Raybaut
-Pierre
> > >
> > > 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: cpas...@cells.es
> Phone: +34 93 592 4428
> +----------------------------------------------------+
>
Uwe Rathmann
> FYI and AFAIK, zooming features (equivalent to QwtPlotZoomer) and object
> interaction features (equivalent to QwtPlotPicker) are much more
> powerful/user-friendly in guiqwt than the one included in Qwt.
The advantage of this technique is that the content of the plot can be
restored from the backing store, when moving the picker ( there is a
similar motivation behind QwtPanner ).
If this becomes a factor depends on how expensive the replot operation is:
in case of plotting an image this is probably no issue, but when having a
heavy line/scatter plot it will be significant. IIRC you didn't migrate
the polygon clipping feature: so I would expect, that when zooming in
deep, moving a rubberband on any line plot will be almost unusable, when
replots are triggered for each update.
One detail, when running remote X11: the technique of using overlay
widgets leads to optimized update regions, what means only the rects
below the previous rubberband/tracker will be transferred over the
network.
Concerning comparing "powerful/user-friendly":
one question would be: is it "easier" to implement some application
specific navigation model with guiqwt classes.
another question might be if the implemented navigation model of guiqwt
is "better", than the one implemented in application code.
But when the application needs to implement their own type of navigation
( simply because they have to ) only the first question is relevant.
ciao,
Uwe
PS: have a look at QwtPlotShapeItem, guess you could replace code of
guiqwt by simply using it