[
https://issues.apache.org/jira/browse/PIVOT-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Brown reassigned PIVOT-474:
--------------------------------
Assignee: Todd Volkert (was: Greg Brown)
This is fixed for ListView and TableView but TreeView has not been updated yet.
> Ensure that selection is visible in ListView, TableView, etc.
> -------------------------------------------------------------
>
> Key: PIVOT-474
> URL: https://issues.apache.org/jira/browse/PIVOT-474
> Project: Pivot
> Issue Type: Improvement
> Components: wtk, wtk-wtkx
> Reporter: Greg Brown
> Assignee: Todd Volkert
> Priority: Minor
> Fix For: 1.5
>
> Attachments: sample.html
>
>
> In most cases, when a component's selection changes, it should be made
> visible via scrollAreaToVisible(). This is currently done when the user
> navigates the view via keyboard (e.g. up/down arrows) but it does not happen
> when the user changes selection state programmatically. The caller must
> manually call scrollAreaToVisible().
> The call to scrollAreaToVisible() can't occur until after the component has
> been laid out. This requires knowledge on the caller's part of how the
> component is implemented internally. While this may be viewed as a simple
> documentation issue, it is compounded by the fact that hidden components are
> not laid out until they are made visible. As a result, some fairly complex
> code is required to ensure that such components properly reflect selection
> state when they are hosted in containers such a CardPane or TabPane, which
> manage the visibility of their children.
> One solution might be to eliminate the optimization that prevents a component
> from being laid out when it is not visible. This would make it easier for a
> calling application to know when it is OK to call scrollAreaToVisible().
> However, this is not ideal since the optimization otherwise seems fairly
> valid.
> Another option is for the skin class to automatically scroll the selection to
> visible when the selection changes. When the component is valid, the
> scrolling could be performed immediately, but would need to be deferred until
> layout() when the component is invalid. This also assumes that we always want
> to scroll the selection to visible every time it changes - this seems
> reasonable, but are there use cases where we might not want to do this?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
