pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Brown (JIRA)" <j...@apache.org>
Subject [jira] Assigned: (PIVOT-548) Fire selection change events when selection changes indirectly
Date Fri, 06 Aug 2010 21:36:16 GMT

     [ https://issues.apache.org/jira/browse/PIVOT-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Greg Brown reassigned PIVOT-548:

    Assignee: Greg Brown  (was: Todd Volkert)

Need to update CardPane, Accordion, and TabPane as well.

> 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.

View raw message