<html>
<head>
<base href="https://bugs.documentfoundation.org/">
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - The text window and the Manage Changes window should be coordinated"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=127061#c4">Comment # 4</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - The text window and the Manage Changes window should be coordinated"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=127061">bug 127061</a>
from <span class="vcard"><a class="email" href="mailto:adalbert.hanssen@gmx.de" title="Adalbert Hanßen <adalbert.hanssen@gmx.de>"> <span class="fn">Adalbert Hanßen</span></a>
</span></b>
<pre>(In reply to Heiko Tietze from <a href="show_bug.cgi?id=127061#c3">comment #3</a>)
<span class="quote">> 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.</span >
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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>