Wednesday, October 22, 2008, 1:56:09 PM, Hussein Shafie wrote: > Daniel Dekany wrote: [snip] >> The bug: When I click on a title in the structure view, the cursor >> jumps to the correct position in views; so far so good. But when I try >> to decrease the height of the bottom view, the cursor suddenly jumps >> away to some apparently random place (several "pages" away from where >> it should be), hence spoiling the whole navigation thing. This doesn't >> occur if I only do a little resizing, but any serious height change >> will trigger this. Interestingly, when I select the title in the >> structure view (for example with double clicking), the cursor will not >> jump away. So maybe it's trivial to fix. > > We currently don't see how this problem could be fixed.
(See below... I hope.) > Workaround (tested with v4.2alpha3, which is very different from v4.1 in > terms of synchronization of the views -- see below): > > [1] Increase the size of the document structure view. > > [2] Click in the document structure view to specify the document region > of interest. > > This makes the document structure view, the ``master view''. > * The master view is the view which has the keyboard focus. > * The caret of the master view is always kept visible. (This is the > cause of your problem) > * The caret position of the master view determines the scrolling > position of the other views. > > [3] Click in the styled view to make it the master view. (This step is > critical to solve your problem.) > > [4] Decrease the size of the document structure view. [snip] Double-clicking is then a simpler workaround (if it works in 4.2 anyway), but doesn't mater now. So, I understand what causes the jumpy cursor phenomena. But... that "The caret of the master view is always kept visible" rule is, well, unusual at best. Maybe I miss something XXE-specific here, but most certainly it's just not a good idea. It's like mixing up what governs what, or worst, it's like an endless loop of what governs what. I mean, the usual approach of text editors is that the cursor is not moved by anything at all but *explicit* cursor movement commands (arrows, home, end, page up/down, mouse click on the document, find text command, etc). According that approach, the cursor definitely should NOT move when I drag the scroll bar with the mouse, nor if I resize a view. It's rather the other way around, i.e, the scrolling position is possibly changed by the *movement* of the cursor (so that the cursor is always visible right after it was moved). So, the cursor governs the scroll position, but scroll position (or any other changes in the view port measurements, like resizing) doesn't govern cursor position. Try a few widely used text editors, and I don't think you will find any that behaves differently. And it has good reason: cursor position is more important, more significant, than scroll position or any other view port measurement (because it's more important if what are you looking at than if how are you looking at it). Where you left the cursor, that's where you expect continuing typing. Like, it's a common editing trick to scroll away with mouse (by grabbing the scroll bar) to look at something, and then just "blindly" type the next character or just hit left+right, and of course both jumps back the view port to where you were, where you currently edit the text. XXE (4.1 at least) however moves the cursor in this situation... but most certainly you don't intend to continue typing exactly at the left-top corner of the screen after scrolling with the scroll bar (or after resizing), certainly not even in the topmost line, so you have to click with the mouse anyway, so moving the cursor to the top-left of the view port didn't help. Note that surely you are a mouse user and also hold the mouse at this moment, as you have scrolled with the scroll bar (requires grabbing it with the mouse), rather than with the keyboard (i.e., with explicit cursor movement). (BTW, funny how deviating from these principles of text editing can hit back at totally unexpected places, like in the case of this ToC navigation issue.) -- Best regards, Daniel Dekany
