I agree that robust keyboard handling is important, especially in text input components. Unfortunately, different platforms have different conventions for keyboard shortcuts, and these can be difficult to generalize. A complete generalization might make use of action mappings or something similar. However, I have tried to keep it simple for now and address the most common use cases. We can always come back to it later in a future release.
FWIW, I think the priority right now should be getting a stable 2.0 release out the door. We're seeing a lot of new interest in Pivot at the moment, and there is a lot of great stuff in this release that these developers will be able to take advantage of. We don't have to try to squeeze everything in right now - the changes we have already made for 2.0 will give us a very solid foundation for moving forward. On Sep 16, 2010, at 9:09 AM, Chris Bartlett wrote: > No danger of us sitting idle post Pivot 2.0 even just relying on the backlog > of issues/tasks/improvements that I have yet to get into JIRA! > > I need to find time to play with the new component before commenting on the > functionality, but as you might have noticed, I strongly favour the use of > the keyboard over a mouse/trackball/trackpad, and as such have come across > various issues (to me, maybe not to others) with the keyboard handling in > Pivot components and Pivot in general. > > Due to the nature of this component, the user's fingers will be in contact > with the keyboard much more than other components. As such I feel that it > would benefit from having as much practical functionality as possible > available via keyboard 'shortcuts'. > > I am yet to write a proper Pivot application 'in anger' having so far been > limited to small tools while evaluating and learning about Pivot. Before I > do, I will need to iron these issues out, but can most likely do that via > sub-classing rather than requiring changes to Pivot. I'll happily > contribute any changes I make if a mailing list discussion suggests they are > wanted. > > Chris > > On 16 September 2010 19:53, Greg Brown <[email protected]> wrote: > >> That is interesting. >> >> My suggestion is to leave the current behavior as is and revisit it in a >> later release, if necessary. As I mentioned, it is the same behavior as in >> earlier releases and doesn't seem to have caused a problem for users yet. >> >> Besides, we have to leave *something* to do for Pivot 2.1 and beyond. ;-) >> >> >> On Sep 16, 2010, at 8:40 AM, Chris Bartlett wrote: >> >>> I thought this is what the ScrollLock key was for, but wasn't aware that >>> Apple keyboards don't have one. >>> http://en.wikipedia.org/wiki/Scroll_lock >>> >>> I think that in some applications Page Up/Down will reposition the caret, >>> but by using a modifier such as Control with Page Up/Down, it would >> merely >>> scroll the viewport. >>> >>> Chris >>> >>> On 16 September 2010 19:26, Greg Brown <[email protected]> wrote: >>> >>>> The easiest solution would probably be to have it override the page >> up/down >>>> key press events and determine what the next line should be based on the >>>> viewport height. >>>> >>>> However, as I mentioned in the other thread, I'm not sure that changing >> the >>>> caret position just because the viewport changes is good UI design. The >> text >>>> editor I use on the Mac (SubEthaEdit) doesn't do it - just like Pivot's >>>> TextArea/TextPane, you can scroll the caret out of view using either >> page >>>> up/down or the scrollbar; however, any key press will scroll it back to >>>> visible. >>>> >>>> Eclipse does reposition the caret on page up/down, but not when the user >>>> scrolls manually, which, to me, seems inconsistent. However, like the >>>> others, a key press brings it back into view. >>>> >>>> G >>>> >>>> On Sep 15, 2010, at 9:36 PM, Todd Volkert wrote: >>>> >>>>>>> - 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... >>>> >>>> >> >>
