Hi to all, other tests, I've just seen in all focusable Text components TextInput, TextArea and TextPane) that the Select All (<CTRL>A) is handled in the right way :-)
I was thinking to propose the same behavior also for Lists, Tables, Trees (when enabled and with multiple selection and not in edit) but I've seen that many applications handle this in different ways, for example Outlook vs Excel, so probably this really makes sense (as a default) only for editable Text components, what do you think ? In TextInput navigation between words (<CTRL> left/right arrow) is not working Then, in all text components the selection of text during navigation between words (<SHIFT> <CTRL> left/right arrow) has some problems, and this is more simple to try than to explain here :-), but I'll try the same a quick explain: selection should be from the starting position (first triggered keys combination) to the current cursor position, and any time the same combination is triggered the cursor should move and so the selection changes, and what is not selected should become selected, and vice versa. Tell me if you need more info. >> - 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. Ok, I'll wait to see these features in trunk so I can try/test them :-) >> - <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. Great, when editing text this is really useful, at least for lazy people like me :-) >However, since Home and End would already do the same thing in ListView, TableView, and TreeView, it doesn't seem to apply there. Yes, I agree, and we are always in time to do it if someone ask ... >> - 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. Ok, I can wait to see this (it's not so important), so we can see what users say or if they'll require it ... >> 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. Good, I have many (web :-( ) applications that handle tons of paged data, so I should be able to do the same with Pivot (even if with Pivot there it's less required) ... >I think this should be left to the application. Changing the selection due to scrolling is, in my opinion, bad UI practice. after thinking better on it, probably Greg has reason. >That is by design. Allowing null values made the implementation more complex than it needed to be (since >the empty string can be used for the same purpose). The same is not necessarily true for TextPane, >though we may want to revisit this and also not allow null values for the "document" property. I agree, so what do you think on a clear method (could already exist, I haven't looked at the code, sorry), and maybe give also a singleton, immutable EMPTY document in this case ? and maybe a similar thing for empty texts (if it's not too overweight) ? >>> - 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. > >Might it make sense to have TextArea override scrollToVisible() to >also update the position of the caret? Though as I think about it, >I'm not sure that would come into play here anyway... > after thinking on it some other time, for sure this makes sense when a TextArea in in edit mode. And in my opinion even on List, Table, Tree when I have many elements (for example 100 or higher), with this feature I could move inside elements in a fast way without using the mouse but only using the keyboard, and it's really a time saver in data-entry applications. To simplify things maybe only when is enabled and selection mode is Single. Uh, another fast navigation tip come to mind (I've seen this time ago in many applications, but with different <CTRL> <other key> combinations) ... for fast selection/deselection of an element (inside List, Table, Tree), what do you think on<CTRL><Enter> ? And maybe on Tree there is another operation that at the moment doesn't have a shortcut: open/close a node, suggestions ? Do you like <Enter> for this ? With this new shortcuts we could handle many operation without mouse ... Comments ? Sorry for the long post, but with this now I have no more ideas on this subject at the moment ... Bye, Sandro -- View this message in context: http://apache-pivot-developers.417237.n3.nabble.com/New-TextArea-component-is-ready-for-testing-tp1457209p1487418.html Sent from the Apache Pivot - Developers mailing list archive at Nabble.com.
