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... > >> > >> > >
