https://bugs.documentfoundation.org/show_bug.cgi?id=162018
--- Comment #4 from Gerry <[email protected]> --- (In reply to Jim Raykowski from comment #3) > For this case: [...9 > Making gtk behave like qt/x11/win in this case seems valid to me. But > perhaps a case could be made for the opposite, make qt/x11/win plugins > behave as gtk, which, after poking at making gtk behave like qt/x11/win, > appears to me to be a much easier hack. > > My experience using the Manage Changes feature is limited to recent > enhancement doings so my vote is with those who actually use the feature. [...] Thank you Jim for looking into the causes of this bug (or different behavior of GTK3). I am regularly using the "Manage Changes" feature and I can elaborate a bit what would be the expected behavior (spoiler: it should be like qt/x11/win): Use case (my standard use case using "Manage Changes"): * When I review a long document that contains many changes, I usually open the "Manage Changes" window and go through the changes one by one as they appear in the list. I may accept, reject or alter/edit the change. When accepting or rejecting, the 'bug' is not relevant, because it works as expected. However, when altering/editing the change (or maybe correcting a typo somewhere in the text), I expect to exactly continue there in the list of changes where I was before. However, the 'bug' causes a jump to the top of the list which doesn't make sense at all. The jump absolutely destroys the work flow, because I have to search again the place in the list where I wanted to continue. --> The GTK3 VCL version should keep the selection like qt/x11/win. Use case 2 -- You are receiving this mail because: You are the assignee for the bug.
