Bug Hunting Session
Bug 90597 - TRACK CHANGES: Uno command for accepting/rejecting change without jumping to next change
Summary: TRACK CHANGES: Uno command for accepting/rejecting change without jumping to ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4.0.0.beta1
Hardware: Other All
: medium enhancement
Assignee: Samuel Mehrbrodt (CIB)
URL:
Whiteboard: target:5.3.0 target:5.2.3
Keywords:
Depends on:
Blocks: Track-Changes UNO-Command-New
  Show dependency treegraph
 
Reported: 2015-04-13 20:45 UTC by Yousuf Philips (jay) (retired)
Modified: 2016-09-21 16:19 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2015-04-13 20:45:48 UTC
In bug 83953, the default behaviour of 'Accept Change' (.uno:AcceptTracedChange) and 'Reject Change' (.uno:RejectTracedChange) was changed to automatically jump to the next change, but we still need duplicates of the original commands that do not jump to the next change.
Comment 1 Luke Kendall 2015-07-04 06:28:55 UTC
I wish someone could find time to work on this enhancement (or even https://bugs.documentfoundation.org/show_bug.cgi?id=38726) - it's desperately needed, for the production of high quality documents.  When tracking changes, a document can quickly become so messy with the visible deltas that you can't see what it would look like with the changes applied.  And if you do accept the changes, LO then automatically jumps to the next change, so in general you have a lot of scrolling to do to locate what you just did, and you lose the "visual diff" you'd get from your own short-term memory at seeing the changes applied.

It makes what should be a simple task, enormously difficult.

I tried simply turning off "Show changes", and using the new Changes toolbar to move from change to change.  It's not ideal, though, as there is only an indication of a specific tiny change, so you get no indication of whether there are any other changes nearby.  I also discovered that if you accept a change, then it also turns the Show Changes back on.  Nor can you see and accept a whole bunch of changes in one operation.

The workaround I've had to adopt is to introduce a spurious change somewhere below a set of changes I wish to accept/reject (like adding a space at the end of a paragraph below), then selecting the text before that, then right-clicking and accepting (or rejecting) changes.  I can of course also accept/reject individual changes as I wish, so this approach gives me as a user excellent control.  If I'm happy with the result, I then delete the just-added space and move to the next set of changes.

Another option for the extension might be to add 3 more controls on the Manage Changes dialogue:

Checkbox: turn off automatically advance to next change
Next change button
Previous change button.
Comment 2 Luke Kendall 2015-07-04 06:29:26 UTC
I should probably have mentioned I'm using v 4.4.4.3.
Comment 3 Luke Kendall 2015-07-04 06:43:44 UTC
I'm finding my workaround is working quite well, since in areas where there are many changes, there's often no need for me to temporarily introduce a spurious change just to prevent the scrolling.

I do notice that there's one small improvement that would further help: if I select a range of text that includes changes, I can right click to bring up the context menu to accept or reject all the changes within.  (That's an excellent feature, BTW.)  But the Accept/Reject buttons on the Changes toolbar are greyed out: I think it would be a nice enhancement if they could be made available directly from there with a single click (instead of requiring: right-click, drag to option, release).

Would you prefer I submitted that as a separate enhancement, however?
Comment 4 Luke Kendall 2015-07-04 07:08:07 UTC
(In reply to Luke Kendall from comment #3)
> I'm finding my workaround is working quite well, since in areas where there
> are many changes, there's often no need for me to temporarily introduce a
> spurious change just to prevent the scrolling.
> 
> I do notice that there's one small improvement that would further help: if I
> select a range of text that includes changes, I can right click to bring up
> the context menu to accept or reject all the changes within.  (That's an
> excellent feature, BTW.)  But the Accept/Reject buttons on the Changes
> toolbar are greyed out: I think it would be a nice enhancement if they could
> be made available directly from there with a single click (instead of
> requiring: right-click, drag to option, release).
> 
> Would you prefer I submitted that as a separate enhancement, however?

Please ignore this - I docked the toolbar, and the Accept/Reject buttons are not greyed out, and work just fine.  I also undocked it, and the same is true.  So I can't reproduce it.  Maybe it was user error.
Comment 5 robert.funnell 2015-11-30 20:52:40 UTC
I use Track Changes heavily, and I was in the habit of taking advantage of the distinction between the behaviour of the accept/reject dialogue (go to next change) and the behaviour of the context menu (don't go to next change). Things have become more difficult now that they both do the same thing. I would really welcome either additional commands, a checkbox or a preference setting. I consider the current behaviour to be a regression.
Comment 6 Robinson Tryon (qubit) 2015-12-10 07:26:33 UTC Comment hidden (obsolete)
Comment 7 cekilch 2015-12-17 20:39:30 UTC
I can only confirm the absolute necessity to change this »new« behavior because anyone working with large documents and wishing to read and evaluate the corrected & changed sentence or doing proofreading of an entire text wishes to stay at the current position – and NOT jump to some other place in the text he or she is absolutely not interested in at this moment.
For me, working with »newer« versions of Libreoffice (showing this behavior) is currently a no-go.
Comment 8 soffioalcuore 2016-06-16 10:43:39 UTC
I agree with what has just been added: It would be very useful for me as user be able to read the sentence for which I've just accepted/rejected a change again to see (and hear) if it's better.
At least an option as has just been mentioned would be nice.
Comment 9 Bart 2016-09-07 10:15:57 UTC
I must admit that present behavior of "Accept Change" (automatic jump to next change) makes everyday editing work truly complicated. As it was said - scrolling back pages and looking for previously verified part of text.
Is there any development on the issue - so there is an optional "no jump Accept Change" ?
Comment 10 Yousuf Philips (jay) (retired) 2016-09-07 11:45:32 UTC
It might be worth reverting to the old behaviour in bug 83953 and then having this enhancement for accept/reject change with jumping, as the change seems to cause more problems than benefits.
Comment 11 Cor Nouws 2016-09-07 15:02:01 UTC
(In reply to Yousuf Philips (jay) from comment #10)
> It might be worth reverting to the old behaviour in bug 83953 and then
> having this enhancement for accept/reject change with jumping, as the change
> seems to cause more problems than benefits.

I think thats a wise suggestion.
Comment 12 Commit Notification 2016-09-07 18:44:14 UTC
Samuel Mehrbrodt committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=583aec2552ed7f8eb22ea7ab7fff7d42e09a506d

tdf#90597 Revert "Jump to next change when accepting or rejecting a change"

It will be available in 5.3.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 13 Samuel Mehrbrodt (CIB) 2016-09-07 18:44:45 UTC
Reverted the change. Should it be backported to 5.2?
Comment 14 cekilch 2016-09-17 11:42:02 UTC
I'm very pleased to see some developments going on – tried LO 5.3 alpha and can confirm that the old behavior is restored.
(Some proposed to give the user the possibility to chose between the old and new behavior – I wouldn't mind any of this as long there is a button to chose the »old« behavior of remaining at the current position and not jumping to the next tracked change.)
As to the question to backport the reverted change to 5.2: definitely yes in my opinion!

Thanks a lot,
cekilch
Comment 15 Yousuf Philips (jay) (retired) 2016-09-17 14:22:16 UTC
Backport patch for 5.2 is in - https://gerrit.libreoffice.org/28979
Comment 16 Commit Notification 2016-09-21 16:19:03 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "libreoffice-5-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=16981dd39a59d77149cbe922eb3f9a8e8fd5c6a6&h=libreoffice-5-2

tdf#90597 Revert "Jump to next change when accepting or rejecting a change"

It will be available in 5.2.3.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.