On 16 September 2010 20:23, Greg Brown <[email protected]> wrote: > 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. > During my upcoming documentation of keystrokes ( https://issues.apache.org/jira/browse/PIVOT-637) I was planning on also seeing if there are any simple improvements that could be made.
One possibility action mappings as you mention, but a first step might just be to refactor out as much logic as possible from the ComponentKeyListener methods into public methods that a user can easily call from their own key handlers or actions. Simple examples might be things like 'select all' and 'deselect all'. > > 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. > > I totally agree. Far less verbose BXML thanks in itself is almost a reason to push out 2.0 right now :) > > 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... > >>>> > >>>> > >> > >> > >
