Version: unspecified (using KDE 4.8.0) OS: Linux It is waaaaaay too easy to accidentally zoom into or out of a single pixel by moving the mouse a little bit when clicking to zoom by fixed factor. There should be a built-in safeguard - either a minimum drag distance required to activate the zoom into/out of rectangle feature, or a warning message when a zoom by an insane factor is about to be performed. Worse yet, KmPlot *will* freeze if zoomed out too much while in fixed grid mode. It probably just starts painting the gazillion labels and gridlines and becomes effectively unresponsive. Safeguards against insane zoom would help prevent this too. Reproducible: Always Steps to Reproduce: 1) Use KmPlot extensively. Actual Results: The problem described in the report. Expected Results: Smooth operation :) OS: Linux (x86_64) release 3.2.7-1-ARCH Compiler: gcc
*** Bug 212178 has been marked as a duplicate of this bug. ***
Git commit 073f782f870e36787d0bb49a81e9e0f581955080 by Christoph Feck. Committed on 17/08/2014 at 21:57. Pushed by cfeck into branch 'KDE/4.14'. Validate custom axis grid spacing - limit spacing when zooming out too far - increase spacing when zooming in too far - only use positive spacing values Related: bug 265408 FIXED-IN: 4.14.1 I have not found yet the conditions for single-pixel zoom, so keeping this one open: M +43 -0 kmplot/view.cpp M +9 -0 kmplot/view.h http://commits.kde.org/kmplot/073f782f870e36787d0bb49a81e9e0f581955080
This might not be exactly "single pixel", that was just a figure of speech. Steps to reproduce: 1) Intend to zoom out by the configured constant factor by pressing Ctrl+2 and clicking with LMB somewhere on the canvas. 2) This time, FORGET to use the heavy blacksmith's anvil you usually put on the mouse in order to PREVENT it from moving between time t0 when you depress the LMB and time t1 when you release the LMB, the two steps that constitute a mouse click. 3) As a result, the mouse probably WILL move by several pixels while the LMB is down. 4) Kmplot WILL register this as dragging a rectangle with the mouse, and WILL zoom "out onto" that rectangle, even if it is very small. This happens A LOT. BOTH a minimum drag distance AND a minimum time between depressing and releasing the LMB should be required for the drag action to be considered non-accidental and handled as a rectangle-zoom rather than click-zoom.
It actually tests both, but uses a hard-coded 100 ms as the time threshold, so if you click slower, you always got the rectangle. I am going to change that to respect the standard startDragTime for 4.14.2, which defaults to 500 ms and can be changed in System Settings. That's why I couldn't reproduce it, clicking with the stylus tip happens faster than with a mouse. I am not quite sure about the "AND" in your last paragraph, though. If we require both conditions fulfilled, you would never be able to mark a small rectangle on purpose. The size threshold is currently very big (an area of 500 pixels, so roughly 22x23 pixels in square). I could reduce this size, though. Ideas welcome.
Oh, forgot: With "AND", you also cannot quickly zoom into a (big) rectangle, if you are faster than those 500 ms.
Git commit e96f2c61786b8150df8722f9b764d366e6d1474c by Christoph Feck. Committed on 17/09/2014 at 13:01. Pushed by cfeck into branch 'KDE/4.14'. Respect startDragTime in zoom handling FIXED-IN: 4.14.2 M +1 -1 kmplot/view.cpp http://commits.kde.org/kmplot/e96f2c61786b8150df8722f9b764d366e6d1474c