> excuse me, on other point proposed what do you think (for example the little > problems I found on TextPane) ?
We can certainly attempt to update TextPane for consistency with TextArea - however, this is one of the reasons I suggested we might want to make TextPane non-editable for this release. As I mentioned in the other thread, I think there is a lot we can do to simplify TextPane, and doing so should make implementing some of these changes easier in the long run. > - Home/End keys: go to start/end of the current line for text elements, and > first/last element in others (Lists, Tables, Trees) Agreed. If we're not currently doing that in ListView, TableView, and TreeView, we certainly can. > - <CTRL><Home> / <CTRL><End>: go to the start/end of the document (all the > text inside the component for text components) ... verify if this makes > sense also for others like (Lists, Tables, Trees) to go to first/last > element ... for consistency between components maybe yes For TextArea, this sounds like a good idea. However, since Home and End would already do the same thing in ListView, TableView, and TreeView, it doesn't seem to apply there. > - Page Up/Down: go up/down by n elements (bounded by first/last), where n is > the size of the current page (for example in a List or a Table with size 20 > elements the page here could be 20) ... Not sure this makes sense. Page up/down is currently handled by ScrollPane, which, in most cases, will be used to host a list, table, or tree. So I think the current behavior is probably OK. We could certainly revisit this later, though. > Note that moving in that data set up/down (to last/first or via page > down/up) could trigger some event like "ask (usually to the server) more > data". This is best left to the application. A custom model can easily handle this. >> You mean when SelectMode is NONE, or when the component is disabled? > If the component is not focusable (or disabled) probably it's better to not > change its selection inside, and move only the current view on it with > scrollbars. Correct - if the component is disabled, it can't respond to keyboard input, so this would be the responsibility of the host container (i.e. ScrollPane). > Otherwise (in any of selection modes ... maybe NOT for SelectMode NONE , on > this we should make some tests to see what is better) reset the current > selection on position (and select the target element where there is a > selectable element) ... for example you can see this behavior on many > products, like Outlook, Excel, etc ... I think this should be left to the application. Changing the selection due to scrolling is, in my opinion, bad UI practice.
