This bug report relates to https://bugs.documentfoundation.org/show_bug.cgi?id=120729 but I have been asked to split the error description, see https://bugs.documentfoundation.org/show_bug.cgi?id=120729#c5. 1. Start with a document with something reasonable in it in order to revise it. 2. Switch on View→Toolbars→Track Changes. 3. Apply some modifications to the sample. 4. Activate Show Changes on the Track Changes toolbar. 5. Locate the cursor between some changes in the document window but not on one of them. 6. Activate Edit→Track Changes→Manage Changes. Current result: The list of changes is shown, but the part shown is unrelated to the document window. None of the changes in it is highlighted. The shown list can be sorted by Author/Date/Comment. It should also be possible to sort it by position in the text (Probably this is the initial sorting order). Expected result: In the order by appearance in the document, Manage Changes should be scrolled such that the logical position of the cursor in the document is reflected in the Manage Changes Window by a line in it corresponding to between the change above and the one below the cursor position in the document window (because in step 5 the cursor was located on an unaltered position in the document). 7. Use the tool button Previous Track Change or Next Track Change to locate some neighbouring change in the document window. Current result: The change in the document window is found and highlighted. This even works, if display of all changes is off, however deletions are just reflected in the cursor position then. That's ok! But nothing happens in the Manage Changes Window. Expected result: The corresponding entry for this change in the Manage Changes Window is also highlighted. If necessary, the Manage Changes Window is automatically scrolled accordingly. 8. Click on a change in the Manage Changes Window. Current result: The change is highlighted and the corresponding change in the document window too. This even works, if display of all changes is off. However deletions are just reflected in the cursor position then. That's ok because it could not really be done differently! 9. Use the tool button Previous Track Change or Next Track Change to locate some neighbouring change in the document window. Current result: The change in the document window is found and highlighted. This even works, if display of all changes is off, however deletions are just reflected in the cursor position then. Again that's ok! But nothing happens in the Manage Changes Window. Even worse: the highlight on the old change stays as it was - now the two windows have become inconsistent! That's not ok! Expected result: The corresponding entry for this change in the Manage Changes Window is also highlighted. If necessary, the Manage Changes Window is automatically scrolled accordingly (as in 7.).
(In reply to Adalbert Hanßen from comment #0) > The shown list can be sorted by Author/Date/Comment. It should also be > possible to sort it by position in the text (Probably this is the initial > sorting order). > Expected result: In the order by appearance in the document, Manage Changes should be scrolled... Sorting is a requirement and covered in the proposal made here https://design.blog.documentfoundation.org/2015/02/19/tracking-changes-with-libreoffice/ (if we use a table it might be easier to click on the table header). Basic implementation has been done and is available when the expert features got enabled (Tools > Options > Advanced). And yes to automatically scroll the list to the right position. > 7. Use the tool button Previous Track Change or Next Track Change to locate > some neighbouring change in the document window. > Expected result: The corresponding entry for this change in the Manage > Changes Window is also highlighted. If necessary, the Manage Changes Window > is automatically scrolled accordingly. > ... > 9. Use the tool button Previous Track Change or Next Track Change to locate > some neighbouring change in the document window. > Expected result: The corresponding entry for this change in the Manage > Changes Window is also highlighted. If necessary, the Manage Changes Window > is automatically scrolled accordingly (as in 7.). Yes, the corresponding list item should be selected on next previous and when selected in the document. I would focus just on this topic here. We also plan to make Accept/Previous jump to the next item (comments on https://gerrit.libreoffice.org/#/c/76719/) and to wrap the list (Next on the last item jumps to the first, see bug 126735). Your input is welcome.
Created attachment 153765 [details] a sample to see a document which has been revised to check the eficciency of current track changes Heiko, I have revised your proposal back from 2015 referred to in your hyperlink https://design.blog.documentfoundation.org/2015/02/19/tracking-changes-with-libreoffice/. I have copied its content and inserted it into a LibreOffice Writer document. Then I used the already existing function to revise this document, e.g. show how some of your proposals are already implemented or to point out, what is still missing with respect to what I have pledged for. All my changes can be seen in the uploaded document, because it has all been done under change tracking. So this is a mild example with only a few corrections. Other documents which I worked on in the past looked much more changed than this one (probably only a few fornmatting canges). In this document you can already see how the current implementation of tracking changes still needs improvement. To really suffer from the tracking issue deficiency however, one would have to do an example of say 100 pages which has been revised by tree persons in sequence.
This big report is still full of information and hard to digest. Keep in mind that developers are usually not reading long text. So how about focusing on the selection? I mean you click on a TC and the respective part in the text is selected, and vice versa.
(In reply to Heiko Tietze from comment #3) > This big report is still full of information and hard to digest. Keep in > mind that developers are usually not reading long text. So how about > focusing on the selection? I mean you click on a TC and the respective part > in the text is selected, and vice versa. Yes, Heiko, being limited in resources one has to decide the order in which one attacks the problems. But in software development an idea what the ultimate target should look like must be present. Sometimes you better ideas arise during implementation. Then it is time to adapt the final target but update it, to avoid going back and forth. On the other hand, there are things which probably can be done with minimum effort and risk, we can label them as quick wins. Therefore it is worth to paint a "big picture" as you did in your report and to paint smaller but still not tiny pictures as I did. Just follow Einstein's rule: Let us make things as simple as possible, but not beyond that point! Devising the targets sometimes exceeds a "one page limit". 1. Being able to sort tracked changes in the List representation by appearance in the document is of the quick win category: There already is a sort function for other columns and probably it is the same sort function which is used to sort any multi column list. When you start Edit>Track Changes>Manage Changes, the List representation is initially sorted by appearance in the document: I just verified it in my revised version of your document: Just open Mange Changes>List and click on the first item in it, then press the arrow down key and observe the document window. To achieve such a test case, I deliberately did several revising readings and applied changes to your text: I wanted changes by time to be in non consecutive order in the text. Once the List is sorted by another column, you won't be able to return to the by-appearance-sorting other than closing Manage Changes and reopen it. Just calling the function which is already used when initially starting Manage Changes would create a sorted list by appearance. But one has to apply it after every tracked editing step in the document because it introduces a new change. Additionally one needs some user interface element for it: an item with a check mark "Order by appearance in the document" which gets automatically unchecked, if one sorts the List representation by some other column. 2. You already can click on an item in the Manage Changes>List to navigate the document to the changed position. So even if the data with the pointers to the changed places do not look well for human readers, one could sort by it. Adding that is of the quick win category. 3. Scrolling the List representation in parallel to cursor movements in the document and highlighting it in the List representation might be out off the quick win category: One has to search for the associated position of the current cursor position in Manage Changes List representation. After locating the corresponding piece in the List, one has to scroll that window such that becomes visible (possibly centred to the displayed window if things are cropped at the top or at the bottom) and then - if the document window's cursor is on a change, it would require to highlight that change in the List representation. If the document cursor is on unaltered text, a line between the two adjacent changes should be displayed. Therefore, your proposed next step, to "focus the selection" is a bit out of the very quick win category - but not very much! Some quick wins are on the way however. 4. My ideas to only highlight changes in the text which are selected according to Mange Track Changes > tab Filter and let all Preceding/Next Change, or Accept/Reject All Changes operate only on the selected set is currently not available. You see it by selecting Insertions in Manage Changes>Filter>Action: Deletions are still highlighted in the document window. Adding such a function probably requires medium effort: It is already there - but only partially: Between the two tabs of Manage Changes, not with respect to the document window. (BTW: I would think of unite the two tabs in one). Finally: all these ideas fit under a common headline: The text window and the Manage Changes window should be coordinated! So we are not inviting someone to get lost in space.
(In reply to Adalbert Hanßen from comment #4) > ... > 1. Being able to sort tracked changes in the List representation by > appearance in the document > ... > 2. You already can click on an item in the Manage Changes>List to navigate > the document to the changed position. So even if the data with the pointers > to the changed places do not look well for human readers, one could sort by > it. > ... > 3. Scrolling the List representation in parallel to cursor movements in the > document and highlighting it in the List Perfect summary, removing needsUX. > 4. My ideas to only highlight changes in the text which are selected > according to Mange Track Changes > tab Filter and let all Preceding/Next > Change, or Accept/Reject All Changes operate only on the selected set is > currently not available. You see it by selecting Insertions in Manage > Changes>Filter>Action: Deletions are still highlighted in the document > window. Let's just gray out the changes filtered in the TC manage dialog. Users would understand this more easily. But I agree that actions should be applied on shown items only.