Repository navigation
Multicursor not displayed with zoom on #156
Description
Original report at SourceForge, opened Sun Mar 14 04:26:54 2010
Python 2.6.4, Matplotlib 0.99.1, PyQT4 4.5.4, Windows XT SP3
When Multicusor is on and zoom too (toolbar icon), cursor line is not displayed when mouse cursor is in the figure. If zoom is off, it's ok. This doesn't appears with Cursor (line present with or without zoom on).
SourceForge Comments
On Fri Jun 4 17:32:00 2010, efiring wrote:
Multicursor is respecting the widgetlock, and Cursor is not; it is not clear why. Maybe both should respect the lock, but only the zoom-to-rect should set the lock. It is not entirely clear to me why a lock is needed even then.
SourceForge History
- On Fri Jun 4 17:32:00 2010, by efiring: assigned_to: 100
Activity
dmcdougall commented on Sep 29, 2012
I don't understand this bug report. This is my example script:
By default, I get the standard arrow cursor regardless of whether the cursor is in the figure or in the axes. If I click the 'pan/zoom' toolbar button, my cursor is the standard arrow in the figure, and it becomes a thick white cross when it's inside the axes. If I then click the 'zoom rect' toolbar button, I get the standard cursor in the figure, and a thin black cross cursor when it's inside the axes.
Am I missing something?
efiring commented on Sep 29, 2012
@dmcdougall Try examples/widgets/multicursor.py. (It is totally broken with macosx backend, so use something else.) On linux, with gtkagg, I think it is working in a reasonable way: the zoom takes precedence, so with zoom-to-rect on, the multicursor is not shown. But if you try the same thing with cursor.py, zoom-to-rect does not display its rectangle, and the cursor is displayed regardless of zoom-to-rect. So these two cursor types are behaving inconsistently with respect to a competing cursor-type operation.
On Mac, with qt4agg backend, you can see the same inconsistency, but the rectangle drawing is broken; I get only a dotted L instead of a solid box for the zoom rect. Tkagg backend works. So, it seems I am running into bugs in qt4agg and macosx backends that are unrelated to the basic cursor-locking inconsistency that is the subject of this issue. I will open two more issues, one for each.
dmcdougall commented on Sep 29, 2012
@efiring With multicursor.py and either pan or zoom-rect enabled, my cursor changes accordingly but the red lines don't follow my mouse movements. With cursor.py, the redlines do follow my movements. Furthermore, with cursor.py, the zoom rectangle is not displayed the first time. Though, subsequent zoom-to-rectangle operations draw the rectangle correctly.
By 'inconsistencies', are you referring to the fact that the red lines behave differently in each example?
Apologies for asking so many question, it's just that I'm actually not sure what these examples are supposed to be demonstrating, so I don't actually know what the expected behaviour is. This is almost certainly my lack of knowledge on custom mpl widgets.
dmcdougall commented on Sep 29, 2012
My previous comment concerns behaviour with gtkagg, by the way. I will try with qt4agg now.
efiring commented on Sep 29, 2012
@dmcdougall Yes, exactly. I think that multicursor is actually doing the right thing here, and it is cursor that is behaving oddly. I think that normally one wants only a single cursor-type marker at a time, so activating zoom-to-rect, which requires its own special box-cursor, should temporarily turn off any prior cursor type--as it does when the default cursor is in use. Whoever originally reported this on sourceforge might have had the opposite opinion, though.
dmcdougall commented on Sep 29, 2012
On a high level, I am not inclined to either agree or disagree with you, since I don't know what the examples are supposed to do. But given your explanation, I am inclined to agree that multicursor is behaving correctly. Also, by the fact it seems to behave consistently across backends (at least between qt4agg and gtkagg), means I'm leaning towards trusting it more.
There are a lot of variables here so I'm going to summarise them in a table so anybody reading this doesn't have to sit and read through our comments.
File: cursor.py | gtkagg | qt4agg | | -------------------|--------------------| | pan | zoom to rect | pan | zoom to rect | ------------------|-----|--------------|-----|--------------| red lines follow? | yes | yes | yes | yes | ------------------|--------------------|--------------------| zoom box drawn? | All but the first. | No | | Box is solid. | |File: multicursor.py | gtkagg | qt4agg | | -------------------|--------------------| | pan | zoom to rect | pan | zoom to rect | ------------------|-----|--------------|-----|--------------| red lines follow? | no | no | no | no | ------------------|--------------------|--------------------| zoom box drawn? | Yes. | Yes. | | Box is solid. | Box is dotted. |Edit: I meant to say multicursor was behaving correctly, not cursor.
efiring commented on Sep 29, 2012
@dmcdougall To clarify, I think that it is the multicursor behavior that is correct, and cursor that needs to be changed. The point is that one is either doing something with the custom cursor or multicursor, or one is zooming, so only a single cursor type should be active at a time, depending on what one is doing.
dmcdougall commented on Sep 29, 2012
@efiring Agh! I meant to say multicursor is behaving correctly.
I am doing just a spiffingly fantastic job confusing myself.
Cursor widget now uses widgetlock; closes Issue matplotlib#156
Merge pull request #1320 from efiring/cursor_lock
dmcdougall commented on Sep 30, 2012
Resolved by #1320. Closing.