Fire selection change events when selection changes indirectly
--------------------------------------------------------------

                 Key: PIVOT-548
                 URL: https://issues.apache.org/jira/browse/PIVOT-548
             Project: Pivot
          Issue Type: Improvement
          Components: wtk
            Reporter: Greg Brown
            Assignee: Greg Brown
             Fix For: 2.0


Currently, selection change events are fired only when an explicit call has 
been made that affects the selection. For example, in ListView, calling either 
setSelectedRanges() or clearSelection() will fire this event. However, an 
operation that indirectly changes the selection state (such as adding or 
removing an item from the ListView's model data) does not trigger an event. 
This was originally done by design - selectedRangesChanged() includes the 
previous selection as an argument, and we didn't want to have to manually 
re-construct that every time the selection changed as a side effect of a model 
change:

 public void selectedRangesChanged(ListView listView, Sequence<Span> 
previousSelectedRanges);

However, in practice, working within this model can be challenging. More than 
once I have registered a selection change listener expecting to receive 
notification of all selection changes, forgetting that it is not designed that 
way. I'm guessing that other developers may be confused by this as well.

So, I am proposing that components that maintain a selection state also fire 
selection change events when the selection changes indirectly. In this case, a 
null value would be passed for the previous selection. This will save the 
effort of re-constructing the previous selection info and will give the 
listener additional information about the nature of the change (i.e. null == 
indirect state change).

This change should also be propagated to TextInput, which has a similar issue 
with character change events. Currently, TextInput fires character change 
events via TextInputCharacterListener and text change events via 
TextInputTextListener. The textChanged() event does not pass the previous text 
value, which is inconsistent with other change events. textChanged() should be 
incorporated into TextInputCharacterListener and should pass the previous text 
value when it is changed via an explicit call to setText(); otherwise, it 
should pass null.

The updated version of TextArea should probably follow the same approach.



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to