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] Updated: (PIVOT-474) Ensure that selection is visible in ListView, TableView, etc.
Date Tue, 20 Apr 2010 12:07:51 GMT

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

Greg Brown updated PIVOT-474:
-----------------------------

    Attachment: sample.html

For what it's worth, Safari automatically scrolls "F" to visible when sample.html is loaded,
and also scrolls "L" to visible when the "L" button is clicked.


> 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
>            Priority: Minor
>             Fix For: 1.5.1
>
>         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.


Mime
View raw message