https://bugs.documentfoundation.org/show_bug.cgi?id=41063

V Stuart Foote <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |needsUXEval
                 CC|                            |[email protected]

--- Comment #45 from V Stuart Foote <[email protected]> ---
(In reply to Buovjaga from comment #44)
> I undid the duplication of bug 95797. Let's keep it as the regression from
> 4.4.7.

;-) care to explain bug 78644?  Actually though there are several facets at
play. But, I don't agree there are two issues to be resolved--an edit cursor in
Tables is handled the same as an edit cursor in any document paragraph.

=-edit cursor and edit View-=

1. Shift+F5 (bug 80960 & bug 82300) recording the last cursor position ViewLeft
and ViewTop into the settings.xml of the ODF archive.  Those set the edit View
on opening of document if an entry is present for user identity. Without the
user identity, the document opens at its Top.  In either case the Shfit+F5
positions view to the last edit cursor location as saved per document in its
settings.xml.

2. Save/Auto-save has never written to the actual document, rather it writes to
temporary copy.

3. Unless you actually save (auto or manual) and also close the document the
active settings.xml is not replaced/updated and the Shift+F5 continues to point
to edit cursor location as was set at opening a document

4. When you save/close and reopen the Shift+F5 edit cursor position and a new
edit View will be where it had been positioned on saving.

Enhancement here would be a method to force update of the settings.xml during
the edit session so that Shift+F5 can be reset during an edit session.  And see
that as related to bug 92821 to establish a number of edit locations to cycle
through.


=-document canvas View-=

This has room for enhancement. And is the main gripe that folks have had--it
did not just start at 5.0

There is currently no mechanism providing hooks to track scrolling view of the
document pane and return to that location.  Sure there are Home, End, PageDown,
PageUp but those are simple repositioning of the canvas frame. The most
granular measure when scrolling the canvas seems to be page units!

Enhancment here would be that Save (Ctrl+S) or Auto-Save would not reposition
document canvas view back to the last edit cursor location. Nor of course to
the edit View (Shift+F5) of the active settings.xml

Rather additional canvas positioning hooks are needed for use in the current
edit session so that canvas view can be kept isolated from the edit cursor.

-- 
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

Reply via email to