XYplorer Beta Club

Isn't it a bit strange what you are talking about?

When I scroll synchronized down to the position where one list ends, I know that the rest of the other is "stand-alone". May it be 2 lines or 20 pages. And I can handle it appropriate.
If you want a special handling of scrolling in this situation: please do it symmetric, i.e. when scrolling synchronized *up*, and one list ends - what do now?

My expectation is, that "some differences" in the lists will be there from time to time:
- one time maybe some at the top
- one time maybe some at the bottom
- and several times some in between.
So top and bottom just are a minority of positions for differences - and I think I will be able to handle them...

OK - the lists could be automatically adjusted, i.e. identical files in both lists could be shown "side by side", while at the position of "missing" files there could be a gap. (This is the escalation, when scrolling "with respect to list-states".)
And files with same name, but different attributes (length, dates, ...) could be marked in different colors...
...but I don't really want to request that

So I think, the user himself can be responsible for aligning both list - may it be down, or may it be up.

PeterH wrote:OK - the lists could be automatically adjusted, i.e. identical files in both lists could be shown "side by side", while at the position of "missing" files there could be a gap.

That's what I had suggested as a separate issue: When 'mirror-find' (not sure if it has a name already but will can it that for the moment) is invoked, if the focused file on left pane is, for example, on line 13 of list, then the name-matched file on right pane should be adjusted to also be at line 13, and if there isn't a match on name, then leave the right pane as is.

This would be much simpler than trying to full sync all files and leave gaps or whatever, and would still aid in aligning the panes so that then sync-scroll could be turned on to move both panes up/down in a somewhat matching fashion.

Sorry - back to the main point I wanted to say:

The very basic of this function would just be the possibility to scroll both panes synchronous, e.g. switching between single and synchronous scroll. But (new idea) with the ability to scroll a bit "spare" up and down.
Imagine: left 20 files, and right only the last 2 of these! It should be possible to align the 2 files from right with their associates on the left. (I hope this explains the idea...)

If you want more "intelligence" at the bottom - you should have it at top, too, and also between both! And I'm afraid this would be *much* more complex to realize. (Sure I would like it - but I wouldn't expect it )

So, what's the verdict?

admin wrote:So, what's the verdict?

I think for now it is the chained method which TheQwerty defined as:

The alignment is never broken when scrolling beyond the end of one pane. The "shorter" pane's contents will continue to scroll out of view and the user must scroll the same amount in the opposite direction to get it back.

So I guess one can align left and right pane the way he/she wants and enable "Sync scrollbar" which will move both panes together and once you disable the "Sync scrollbar" function, everything returns to as it was previously.

serendipity wrote:

admin wrote:So, what's the verdict?

I think for now it is the chained method which TheQwerty defined as:

The alignment is never broken when scrolling beyond the end of one pane. The "shorter" pane's contents will continue to scroll out of view and the user must scroll the same amount in the opposite direction to get it back.

So I guess one can align left and right pane the way he/she wants and enable "Sync scrollbar" which will move both panes together and once you disable the "Sync scrollbar" function, everything returns to as it was previously.

I thought I saw in prior page that serendipity preferred the Magnetic variant, which TheQwerty did also, and IF I understood how it'd function correctly, I believe I would also...with Chained being the second best.

Because while scolling shorter pane to blanks makes some sense, so does the auto-resumption of scrolling when the last match-up comes back into view which is what I saw as the Magnetic vers.

And I still believe that a related but slightly separate (user invoked when desired) function of auto-positioning the current focused item on one pane to the matching item on other pane (ala x2) should be part of this overall feature.

Reply from dev: forget about additional blank space in the shorter list. This is not possible.

Given this fact, what is the verdict now?

I would prefer an menu command in first place
(and had so the possibility of using an CTB and/or assign an shortcut on my own)
to toggle the use of SyncScroll.

Enabling SyncScroll on the fly by an shortcut could lead to (selecting) problems, i could imagine.



My imaged usage:

I would scroll in both panes each to an line i want,
no matter if 1:1 or 23:456 or what.


If i then enable SyncScroll
i would use all the current possibilities to scroll the list as right now...
.. but the "other" pane just scrolls too the same amount of lines.



If one pane reached the end...
... i hear an beep (or see an yes/no dialog?) (but i think i seeit on my own if one pane stops),
the scrolling for the shorter pane stops and remembers the current line,
the longer are still scrollable,
(if i scroll back again, the shorter scrolls synced again too IF the remembered line is reached)

Vise versa if the other pane now reached an end.

.

admin wrote:Given this fact, what is the verdict now?

Still think the Magnetic way is best, and I agree with Stefan in that this should be a menu item (within Panes).

TheQwerty wrote:

admin wrote:Given this fact, what is the verdict now?

Still think the Magnetic way is best, and I agree with Stefan in that this should be a menu item (within Panes).

Let's see if I got it right: When you switch on Magnetic then the current difference in topindex (between the panes) is stored and kept as long as possible. If not possible the inactive pane stands still. So I would just have to store one number, say minus 16.

admin wrote:Let's see if I got it right: When you switch on Magnetic then the current difference in topindex (between the panes) is stored and kept as long as possible. If not possible the inactive pane stands still. So I would just have to store one number, say minus 16.

I do believe that should work, but it's early here and while I've played with makecoffee; I haven't gotten any caffeine into my body yet.

TheQwerty wrote:

admin wrote:Let's see if I got it right: When you switch on Magnetic then the current difference in topindex (between the panes) is stored and kept as long as possible. If not possible the inactive pane stands still. So I would just have to store one number, say minus 16.

I do believe that should work, but it's early here and while I've played with makecoffee; I haven't gotten any caffeine into my body yet.

And the synch scroll should auto-reset whenever one of the panes changes location, or?

admin wrote:And the synch scroll should auto-reset whenever one of the panes changes location, or?

I'm not really sure, I hadn't considered location/tab changes (they don't factor into how I considered I'd use this feature)...

I want to say it should be treated like VF, and given a Persist option. When Persist is on the topitem difference would be recalculated on any location/tab changes; after the list is scrolled to focus items from history, etc. With Persist off, then any location/tab change would automatically disable synch scroll; and the user would need to turn it back on when they want it again.


There's certainly room for compromise between these two options, but I'm confident it will make things complicated and I'm not sure it is really desired/needed.

Seems I'm with Stefan.

admin wrote:And the synch scroll should auto-reset whenever one of the panes changes location, or?

For me: yes.

Yes, i would like the magnetic way too (like i mentioned before) and since you said extra blank space is not possible then chained is ruled out and glue method would be too annoying (at least for me).

And the synch scroll should auto-reset whenever one of the panes changes location, or?

Yes. Because sync scroll should apply to only two visible panes when the command was triggered.
Others can add to following list.
Sync should stay when user:
1) Goes to other locations and returns back to same two tabs.
2) Swaps panes

Sync should break when user:
1) Goes to another location and re-enables sync there. (not sure if multiple sync scrolls should be supported)
2) Changes location in any of the Synced tabs.
3) Restarts XY (should it be ON across sessions?)

Additional wishes (low prio):
1) Some way to distinguish the two synced tabs (maybe coloring? useful when several tabs are open)
2) a shortcut to jump to two synced tabs.