pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "aappddeevv" <aappdde...@verizon.net>
Subject RE: [RFC] Selection change events
Date Fri, 25 Jun 2010 02:12:28 GMT
This sounds good. But why would you pass null? Should it not be be the
previous selection info (the current selection prior to changing it
indirectly? This would be consistent with doing it "directly." 
-----Original Message-----
From: Greg Brown [mailto:gkbrown@mac.com] 
Sent: Thursday, June 24, 2010 3:34 PM
To: dev@pivot.apache.org
Subject: [RFC] Selection change events

Hi all,

I am thinking about making a change to how selection change events are fired
and I would like to hear your feedback. 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, I have found this to be a bit 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. If I am getting tripped up by this, I'm guessing that other
developers might be 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).

Please let me know what you think.

Thanks for your input,
Greg



Mime
View raw message