Hi Greg, excuse me, on other point proposed what do you think (for example the little problems I found on TextPane) ?
Now I'll try to simplify some points, with some general rules (for all components that accept input, but maybe some of them are only for those containing many data like Lists, Tables, Trees): - Home/End keys: go to start/end of the current line for text elements, and first/last element in others (Lists, Tables, Trees) - <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 - 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) ... 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". On Lists It's true that giving the initial letter goes to the first element with it, but for example if I'd want to go to the first element and I don't know the letter (in "Kitchen Sink" many Lists doesn't start with "A") I have to try until I find that right ... but on List this makes sense, I like it. Instead, on Tables and Trees this method is not valid. So my proposal is to ADD handling of previous key combinations to have more range positioning on elements. In case of Edit mode I don't know the behaviors just described, if they are still correct ... but maybe yes, we could think to trigger an event and let the developer handle it (if wanted), otherwise go with the behaviors just seen. In this way if a User is editing a row in a data table, the developer could handle an event like "ask edit mode ?" and maybe ignore it. > 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. 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 ... Really I think this is a little but important feature because in this way we could let users do (fast) navigation inside components, all with keystrokes (a great time saver respect to the mouse): precise positioning with arrows (up/down), paging positioning via page keys, and first/last positioning via home/end (or <ctrl>home/<ctrl><end> depending on cases) keys, really useful with much data ... you like it ? I hope to be more clear now :-) , if not, tell me ... One time it will be clear what to do, tell me and I'll create a ticket for this, with some of these info as description. Comments ? Sandro -- View this message in context: http://apache-pivot-developers.417237.n3.nabble.com/New-TextArea-component-is-ready-for-testing-tp1457209p1479469.html Sent from the Apache Pivot - Developers mailing list archive at Nabble.com.
