Possible bug in RangeSelectionOverlay.

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Possible bug in RangeSelectionOverlay.

Jordan Ilott
When the metadata name attribute of a RangeSelection tool is changed to something other than 'selections' the overlay does not appear to correctly handle the change. Setting the metadata_name attribute of the RangeSelectionOverlay seems to prompt the overlay tool to search for a range which contains all of the selected points. The code indicates that it treats the metadata as a selection mask rather than a range. An exception arises when attempting to find the range that contains all of the points in the mask and appears to be related to finding the runs in the selection mask.

I don't think that there is some design intention that I'm violating. I simply wish to manage multiple range selections on the same datasource, the assumptions made by the RangeSelectionOverlay appear to prevent my doing this. The only reason I can see to use the selection mask is to support appending to the selection. Rather than use a mask and make an assumption about the selection based on its name, why not just make the metadata a list of tuples and append to it? Or perhaps there should be no tuples and only a mask should be used. I'm not sure what could be done that wouldn't break backwards compatibility.

I've created an issue on GitHub: https://github.com/enthought/chaco/issues/113

I'm not sure what the etiquette on cross posting between this list and the GitHub issues function is. My intent was to add value with some thoughts on the problem and to solicit ideas for solutions. I would consider writing the fix myself if I understood what some of the broader implications might be.

Jordan

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Possible bug in RangeSelectionOverlay.

Jordan Ilott-2
A little further digging has revealed that  RangeOverlaySelection._get_selection_screencoords is assuming that there is a single selection mask. RangeSelection appears to treat the selection mask metadata as a list of selection masks. Simply looking at the first element in the list resolves the problem except that when the range is deselected, RangeSelection deletes all of the masks rather than simply setting each value to False. Again, not being sure of why this behavior has been implemented, I'm not certain what the complications are with changing(fixing?) it.

At any rate, it's a little complicated to connect things. It's necessary to set the mask_metadata_name attribute of the RangeSelection and the metadata_name of the RangeSelectionOverlay to the same value in order to have any chance of success with using a custom metadata name for the RangeSelection tool.At the very least, RangeSelection should match the expectation of RangeSelectionOverlay by switching to a mask mode anytime the metadata_name trait is set to something other than 'selections'

Jordan


On Tue, Apr 16, 2013 at 11:22 AM, Jordan Ilott <[hidden email]> wrote:
When the metadata name attribute of a RangeSelection tool is changed to something other than 'selections' the overlay does not appear to correctly handle the change. Setting the metadata_name attribute of the RangeSelectionOverlay seems to prompt the overlay tool to search for a range which contains all of the selected points. The code indicates that it treats the metadata as a selection mask rather than a range. An exception arises when attempting to find the range that contains all of the points in the mask and appears to be related to finding the runs in the selection mask.

I don't think that there is some design intention that I'm violating. I simply wish to manage multiple range selections on the same datasource, the assumptions made by the RangeSelectionOverlay appear to prevent my doing this. The only reason I can see to use the selection mask is to support appending to the selection. Rather than use a mask and make an assumption about the selection based on its name, why not just make the metadata a list of tuples and append to it? Or perhaps there should be no tuples and only a mask should be used. I'm not sure what could be done that wouldn't break backwards compatibility.

I've created an issue on GitHub: https://github.com/enthought/chaco/issues/113

I'm not sure what the etiquette on cross posting between this list and the GitHub issues function is. My intent was to add value with some thoughts on the problem and to solicit ideas for solutions. I would consider writing the fix myself if I understood what some of the broader implications might be.

Jordan


_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev