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