QwtPlotZoomer locks up, possibly bug?

[Neekeetos]

There are no "autoscale" parameter, that could be reset.

There is, when you say "autoscaling gets disabled" , "re-enabling autoscaling", or, reading your links on Plot api, "Disable autoscaling", "Autoscaling is enabled by default" etc. Means there is underlying parameter for each scale which gets set or reset when you enable or disable autoscaling, you call it doAutoScale inside library.

The zoomer maintains a history of the scales it had set. When the application code changes the scales behind the back of the zoomer ( f.e by re-enabling autoscaling + replot, or using it in combination with panning ), this history ( the zoom stack ) is not changed. Understanding this it should be no surprise, that you don't get the same scales when you go back the top of the zoom stack, than those you get from autoscaling, when the plot contents has changed in the meantime.

Uwe, it is always surprise, because for plot it is normal to expect that when you manually set range for particular scale this range is not reset even after new data is assigned, but for zoomer, it is just you implemented it the way, that zoomer is bound to fixed ranges, it is not obvious. I think now that it is not about autoscale disable/enable( and thus switching autoscale on/off is a true workaround), it is a zoomer that is not working correctly - ie what is the point for zoomer to keep using invalid scales? At least outer scale in zoom stack (ie bondary) should be updated with data changes, otherwise it is not possible for user to access a data outside old boundary for no reason.

For these situations the application code has to adjust the zoom stack manually.

in my opinion these situations are 100% of all, so maybe it is a library to adjust zoom stack, at least in cases when data becomes inaccessible within old ranges?

[Uwe]

There is, when you say "autoscaling gets disabled" , "re-enabling autoscaling", or, reading your links on Plot api,

O.k. but don't blame the documentation for not reading it.

Uwe, it is always surprise, because for plot it is normal to expect that when you manually set range for particular scale this range is not reset even after new data is assigned, ...

This is exactly how it is implemented - what's your point ?

... but for zoomer, it is just you implemented it the way, that zoomer is bound to fixed ranges

I have to repeat myself: once you have understood that the zoom stack is simply a history of the scale ranges recorded by zoom operations it is very obvious what happens. If this is good or bad is a different story - the point is that you can only help yourself when you know what is going on.

Or more explicit: modify the rectangles in the zoom stack, whenever you want to have different rectangles in the zoom stack.

I think now that it is not about autoscale disable/enable( and thus switching autoscale on/off is a true workaround), it is a zoomer that is not working correctly - ie what is the point for zoomer to keep using invalid scales?

The idea of the zoom history is very straight, understandable and working correctly. It is o.k. for most of the applications. because they don't change the scene while zooming.

The problem is the concept not its implementation. It should be a common navigation stack for the plot - not a zoom stack inside a single zoomer. This way panning, zooming and whatever could be combined more easily. Nevertheless the application code will have to decide how this stack has to be fed.

But in general the default behavior of a library rarely meets the requirements of an application in all details. A good library design offers a reasonable default implementation but is aware that the application will have to modify it. You seem to call this "workarounds" - but it is simply your job as application developer.

Uwe

[Neekeetos]

But in general the default behavior of a library rarely meets the requirements of an application in all details. A good library design offers a reasonable default implementation but is aware that the application will have to modify it. You seem to call this "workarounds" - but it is simply your job as application developer.

So, why do you argue? Im calling this workaround because for me it is behaving incorrectly. And because of this I've created this topic. Regarding my job - for me, normal process is to use feedback to correct issues, not building workarounds. That is so because of two reasons - workarounds are impossible to support, second - development of (in this case your) library is not suffering from hidden bugs. For now QWT have no documents other than class reference, no description of logic behind = no guaranty that you will not change something, happily breaking my code (note - code is based on assumptions, because you don't state anything explicitely ).

[Uwe]

So, why do you argue? Im calling this workaround because for me it is behaving incorrectly.

QwtPlotZoomer does something different than what you need, but that doesn't mean that it is wrong. Call it whatever you want, but for the maintainer of a library "incorrectly" means having to fix a bug, while changing the concept or design of a class is something completely different. In fact changing the behavior of the zoomer so that you would call it "correct" would break all existing applications relying on the current implementation.

The documentation is far from being good, but in your particular case all I can see is that you had problems with the very, very basics of the plot widget and out of frustration you were complaining about the documentation without even having read the 3-4 most basic methods ( stable since 15 years ) every application has to use.

And instead of trying to find out what needs to be done and if this is really that difficult you ...

... no guaranty that you will not change something, happily breaking my code

Then read my promise that I will change something breaking your code :

• The concept of the zoom stack is too simple and needs to be replaced by a more general navigation stack.
• But even more important: Qwt has to be adopted to Qt5 where you also have the scene graph that doesn't work with widgets anymore.

Uwe

[Neekeetos]

but for the maintainer of a library "incorrectly" means having to fix a bug, while changing the concept or design of a class is something completely different. In fact changing the behavior of the zoomer so that you would call it "correct" would break all existing applications relying on the current implementation.

That is the whole point of doing library - it is not about internal structure,classes but about api, nobody should care of internals. The fact that it is not possible to apply a minor change to behaviour just prooves internal structure of a library is not adopted good enough for its task, not about how well user of a library can read documentation or library code.

The documentation is far from being good, but in your particular case all I can see is that you had problems with the very, very basics of the plot widget and out of frustration you were complaining about the documentation without even having read the 3-4 most basic methods ( stable since 15 years ) every application has to use.

It is not stable, examples of fifth version do not work with 6th...

And instead of trying to find out what needs to be done and if this is really that difficult you ...

To me it is really difficult to prove you simple basic things,because I solved my problem in second message of a thread if you remember, and I also found a cause for it.

Then read my promise that I will change something breaking your code :

• The concept of the zoom stack is too simple and needs to be replaced by a more general navigation stack.
• But even more important: Qwt has to be adopted to Qt5 where you also have the scene graph that doesn't work with widgets anymore.

Ok, that is the main thing here. You put some effort to guide me to "correct way of doing things", like reading documentation and study methods etc, but you admit now that there is no correct answer, nice . In my attempt I basically did nothing but manually corrected axis scales. And you are telling me that even this simple thing will break the whole application because of scene changes? That is absolutely what I was talking about previously, something Im avoiding!

[Uwe]

The fact that it is not possible to apply a minor change to behaviour just prooves internal structure of a library is not adopted good enough for its task, not about how well user of a library can read documentation or library code.

Or it proves the weakness of both - but both are no excuse for complaining about the docs instead of trying to read them.

Concerning the design of how to set the scales: tell me what is bad or hard to understand about following methods:

• QwtPlot::setAxisScale()
• QwtPlot::setAxisAutoScale()
• QwtPlot::replot()

You can also send me patches for the documentation writing all what would have helped you with your situation.
I'm open to suggestions - but please no more of this unspecific noise.

Ok, that is the main thing here ..

These statement are completely unrelated to what you had quoted. What do you expect from a discussion when you don't read or try to understand the other side - winning by writing the final posting ?

Uwe