parallel navigation feature request

[Avner Shapiro]

it would be nice to add an option for "parallel navigation".

usage:
I have 5 docs, all very similar (even the same pagination), but differences exist.
I want to examine them all together (either to proofread them, or to compare them).
when I scroll one of them, I want to preserve the current page when I switch to another one.

attached a crude patch. but it works always if applied, which is clearly undesirable.
the idea of the patch is to save the old tab's positioning data (some of it at least - the things that interest me here and now) and apply it to the new current tab.
the patch is not against the newest version, but against Debian's stable (0.4.12), but it should suffice for acquiring the idea.

my suggestion is (different from the patch):
- take all the positioning stuff (page, left/top, rotation, scale mode and factor, etc. history should be considered too) out of DocumentView, into a new Navigation class.
- when a tab is created (that is, new DocumentView), a new Navigation instance is created for it too. all methods related to positioning will now be handled by this new class.
- a new GUI option: link this tab with another for parallel navigation. when this is selected, current tab's Navigation is deleted (actually unref-ed, which may imply deletion), the other's refcnt is increased and it's shared among both.
- unlinking can be implemented easily too the same way (unref, create new Navigation for current, and copy the current data into it).

that way no extra save/restore is needed at all.

I'm not a C++ programmer nor a GUI one, so I won't provide a full patch. but if someone can implement it I think it's a very good feature.
thank you.

[Adam Reichold (adamreichold)]

Hello Avner,

thank you for your suggestion and code contribution. Also, I am sorry for taking so long to reply to your report, but I wanted to try out a few approaches to this before answering.

As you say, the patch is a proof of concept implementation that cannot be merged as-is. After reviewing your use case and remembering a few other wishlist bugs from the past, I think it would be better if we implemented a split view feature to facilitate proof reading documents with or without synchronized navigation. Having both document visible at once should make this particular task much easier and the parallel navigation feature can then be implemented by directly connecting signals and slots from the two views of a split with each other.

The linked branch add-split-view contains another proof of concept implementation, albeit one that does not affect the normal usage of the application. It adds two configurable actions to the main view and tab context menus called splitViewHorizontally and splitViewVertically, i.e. they have to be added to these menus using the "Interface" tab of the settings dialog. Using these, a single main view can be split into several views which use parallel navigation if the "Synchronize split views" setting is enabled (which is the default). Theoretically, this can be nested, but if have not really tested this until now.

Apropos testing, please try out this branch and determine whether it helps your use case. Also note that there are certainly a lot of places where the UI does not work as expected, e.g. restoring closed tabs is not possible for split views and a split view stays a split view even if the second view is closed. Also restoring tabs looses the splitting relationships. But they should not impede any existing functionality or work using the feature for proof reading. Also I would be glad if you could for any bugs, i.e. program crashes and blocking inconsistencies with or without using the feature.

As it is, the necessary code changes are quite minimal but also pretty invasive, so I am not yet sure whether I would merge this before releasing 0.4.17 or not...

Best regards, Adam.