more rubberbanding & interactions on ROView - Moose-dev

19 Oct 2012

With the recent integration of RORubberBand, I have then gone to use it 
in my application.  What arises is that while the implementation works 
well within a single script in ROExample, it is not so well when the 
creation of elements is more spread out in different parts of the code, 
since these different parts do not have access to the same instance of 
RORubberBand.  So some further thoughts on rubberbanding for discussion...

1. Since the rubberband operation is between elements, perhaps this 
should not be stored inside individual ROElements but more globally in 
ROView.  That is, perhaps ROView would have its own interactions.

2. Currently to avoid the MNUs due to the target filter condition 
processing edges and elements with nil or unsuitable model, in 
(RORubebrBand>>initializeElement:) I used (candidateTarget 
getInteraction: self ifPresent:) where it is the 'self' that ensures 
that source/target elements being compared are applicable to a 
particular RORubberband.  It is that 'self' that is hard to distribute 
to elements that are created from different parts of the code.  Perhaps 
this mechanism could be replaced by tagging RORubberBand defined in 
different elements with a common symbol eg #rubberband1

Or tag the elements associated with a particular rubberbanding are just 
tagged the same as the RORubberBand instance stored in the ROView.

3. Perhaps not bother with trying to ensure no exceptions occur in the 
execution of the target filter condition, and just mask them out.  
Rather than interrupting the program with a MNU, targets elements are 
simply excluded if the filter.

What are your thoughts?

cheers -ben