pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noel Grandin <noelgran...@gmail.com>
Subject Re: [RFC] Selection change events
Date Fri, 25 Jun 2010 13:24:31 GMT
 Hi

OK, I see your case.

I'm just concerned about the "sometimes previousSelected is available, sometimes it's not"
situation.

Perhaps we should rather just take the complexity knock and always work out the previous selection
- what was the
problem here again?

-- Noel

Greg Brown wrote:
> Hi Noel,
>
> I did think about removing that argument, but there are a few reasons why I didn't think
it was the right approach:
>
> 1) All of our other property change events carry a previous value, so this would create
an inconsistency.
>
> 2) I think there are potentially valid use cases for it. Let's say I have a list view
containing 10 image file names. Next to the list view I have a grid view containing image
thumbnails. When an image is selected, I want to set a background color for the corresponding
image; when deselected, I want to clear it. It will be more efficient to implement this logic
if I have access to the previous selected indexes. This is a contrived example but I'm sure
that someone will run into a real-world use case for it.
>
> 3) It is already supported and carries almost no overhead, so taking it out would be
removing potentially useful functionality.
>
> Another possibility is to create a new listener interface to fire this event, similar
to TextInputTextListener, which defines textChanged() and does not include the previous value.
However, we already have ListViewSelectionListener, so I'm not sure what we might call it.
That's how I came to the idea of simply overloading the previous value argument.
>
> This does make me realize that TextInput is also a bit inconsistent, since setText()
fires textChanged() and does not pass the previous value. So it may actually make sense to
consolidate TextInputCharacterListener and TextInputTextListener into a single interface and
take a similar approach there.
>
> G
>
> On Jun 25, 2010, at 4:25 AM, Noel Grandin wrote:
>
>> HI
>>
>> I think your change is a good idea, but I don't really like using null
>> as an indicator of something special.
>> It sounds like an invitation to make mistakes about when the parameter
>> is or is not useful.
>>
>> Why don't we just make this a special case and drop the "previous"
>> parameters?
>> I can't see many callers wanting to make use of it, and they could
>> always keep track of it themselves if they really need to.
>>
>> -- Noel
>>
>> Greg Brown wrote:
>>> 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