XYplorer Beta Club

I am starting to get into DP and its becoming very useful especially at work.
Coming to my wish, I am comparing long list of files and almost always i end up scrolling each list inch by inch which is kind of slow as i have to always re-align them together.
Could you provide a key which would sync both lists to scroll together after i have aligned them the way i want?
Also, if one scroll bar hits the bottom then scrolling should stop on both panes until i use the key again to release sync.
Cooler would be to provide an accelerator (i see that shift+alt is free) which one can hold while scrolling and both panes would scroll.

x2 has a variant of this via "Mirror scrolling" via their Go-To menu...

As you move the focus in the active pane, x2
automatically moves the focus to the matching item in the inactive pane. It scrolls the inactive pane as required.
If x2 can’t find a matching item in the inactive pane, the focus in the
inactive pane stays on the last focused item. It will move again only
when x2 finds another match.

But having the panes be able to 'lock' to each other is definitely a request that makes sense.

serendipity wrote:I am starting to get into DP and its becoming very useful especially at work.
Coming to my wish, I am comparing long list of files and almost always i end up scrolling each list inch by inch which is kind of slow as i have to always re-align them together.
Could you provide a key which would sync both lists to scroll together after i have aligned them the way i want?
Also, if one scroll bar hits the bottom then scrolling should stop on both panes until i use the key again to release sync.
Cooler would be to provide an accelerator (i see that shift+alt is free) which one can hold while scrolling and both panes would scroll.

Yes, might be doable with shift+alt+wheel. I only wonder about the specifications you give and if they are okay for most users. Are there any de facto standards for sync scrolling? Is it expected that sync scrolling stops when one of the lists is at the end?

Not sure about any standards, but having to have a wheel shouldn't be a requirement...rather, a wheel could be an alternative for those who have one...us touchpad'rs don't have wheels, remember? That's where holding down (or toggling => which may be better) a key combo while dragging scroll bar should be also possible.

As far as handling at end of list: I wouldn't object to stopping when shorter list hits end but maybe allowing blank space to be used so that items futher up/down on longer list could be accessed while still keeping sync as 'locked' in...that is, suppose left side had files named "J" to "R" while right side had full "A" to "Z"...without the blank space on left, you couldn't get to file "I" or "S" on right without releasing lock, and you still may want to keep J-R exactly in sync.

I wouldn't mind what happens when the shorter list is at the end. Maybe it would be better if both sides would *not* become asynch in this situation?

But don't know, if you thought of that: if one side misses some files (in the middle), I must be able to asynchronous scroll any side to re-align, then again scroll both synchronous.

First thanks for that suggestion, can come in handy from time to time.

My Senf on this topic:

I would prefer an menu command (and so the possibility of using an CTB) to just enable SyncScroll.
Like "View > Sync Panes"

If i enable SyncScroll
i would use all the current possibilities to scroll the list as right now...

but if i scroll the top or bottom most entry of one of the panes out of view -
- then the other pane should scroll the same amount of entries in the same direction
(if possible, means if there are any more entries. If not, just do nothing. I see it on my own that the end is reached)

To make this clear: it would be no matter if i am left at file # 163 and right at # 21, or both at #1.

@serendipity: welcome to the DP users



.

I won't take part in the discussion because I virtually don't use DP. Let me know if you reached an agreement on how this should work.

I have not tried other managers to see what the de-facto standard is, but i suggested what felt intuitive to me while working in dual pane.
Regarding the behavior when one list hits the end, another possibility (more work for you) would be:
The longer of the two lists keeps scrolling down until its end and when i scroll back up it picks up the shorter list at the synced point and scrolls up together with it.

@JC: I didn't mean to say that wheel scrolling should be the only way to do it, it would be in addition to the keyboard shortcut.

@Stefan: Thanks!

serendipity wrote:The longer of the two lists keeps scrolling down until its end and when i scroll back up it picks up the shorter list at the synced point and scrolls up together with it.

That's sorta what I said in my "A"-"Z" post, but had suggested that short list scroll into blank area as needed.

j_c_hallgren wrote:

serendipity wrote:The longer of the two lists keeps scrolling down until its end and when i scroll back up it picks up the shorter list at the synced point and scrolls up together with it.

That's sorta what I said in my "A"-"Z" post, but had suggested that short list scroll into blank area as needed.

ah sorry, i just skimmed your post.
But should the shorter list go blank? I know winmerge does this, but maybe with file lists showing the other list anyway wont be harmful. thinking loud here.

serendipity wrote: ah sorry, i just skimmed your post.

No problem...thought you maybe had.

But should the shorter list go blank? I know winmerge does this, but maybe with file lists showing the other list anyway wont be harmful. thinking loud here.

I'm also just throwing ideas out...to me, it's like some text compare utilities...where one side may have much more text than other...and they often scroll into blank as needed so you know that right side is WAY below the end of left side, for ex.

'Cause if short list stopped, and long list kept scrolling, it seems to me that would be a bit confusing..but others may disagree.

PeterH wrote:But don't know, if you thought of that: if one side misses some files (in the middle), I must be able to asynchronous scroll any side to re-align, then again scroll both synchronous.

And as I wrote, it should have an relatively easy way to toggle 'sync-lock' on/off (without a TB icon as my TB is FULL) so that one could un-lock, scroll one side slightly and then re-lock it.

In lock mode, I'd suggest that any up/down via arrow/page keys or either scroll bar should apply to both sides.

j_c_hallgren wrote:

serendipity wrote: But should the shorter list go blank? I know winmerge does this, but maybe with file lists showing the other list anyway wont be harmful. thinking loud here.

I'm also just throwing ideas out...to me, it's like some text compare utilities...where one side may have much more text than other...and they often scroll into blank as needed so you know that right side is WAY below the end of left side, for ex.

'Cause if short list stopped, and long list kept scrolling, it seems to me that would be a bit confusing..but others may disagree.

PeterH wrote:But don't know, if you thought of that: if one side misses some files (in the middle), I must be able to asynchronous scroll any side to re-align, then again scroll both synchronous.

And as I wrote, it should have an relatively easy way to toggle 'sync-lock' on/off (without a TB icon as my TB is FULL) so that one could un-lock, scroll one side slightly and then re-lock it.

In lock mode, I'd suggest that any up/down via arrow/page keys or either scroll bar should apply to both sides.

The reason i am wondering about blank on one side is, if i want to re-align my list with another (I have bunch of duplicates sometimes) item which might be far below on one list than other, then i have to scroll back up on the blanked list to select the relevant item.
Oh wait, but then when i re-align (toggle sync-scroll) the blanked list should be visible again right? in which case i am tending towards the the blank idea. alternatively, maybe just grey the shorter side indicating its not synced.

And yes, if Don provides toggle in the menu then mousers can assign button and keyboarders can assign key. Win-Win.

Well, as a possibly separate item, we could have the x2 style where it (as i understand it) would match up the current focus item on active pane with same item on inactive...

This presumes that at least those files/folders are named same which may not always be case, but it would help to begin the lock process by auto-matching one item wherever that item was on list, be it top/mid/bot/etc.

But I see sync-lock as being that both panes move exactly as one and if one goes past available items, it would show as blank or maybe some minor color variant but that then requires a separate color config be available for those with wacky color schems.

I think we really have three options (which I think you've all mentioned already). To make this a little easier let's consider how the top item in each pane is connected when enabling synchronization.

1) Chained: 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.

2) Glue: The alignment pulls apart when scrolling to ensure the "shorter" pane is displaying content. However, the items are still sticky, so when the user changes direction each pane resumes scrolling at that point. The original alignment is lost and replace with the alignment that was in place when the user changes direction.

3) Magnetic: The alignment pulls apart when scrolling to ensure the "shorter" pane is displaying content, like Glue. However, the items don't re-align when the user changes direction, instead the pane will resume scrolling when the original alignment is restored.


Personally, I'd prefer the magnetic option, as my main goal would be to establish alignment and keep it, but think the empty panes in the chained method would be confusing (and even a little annoying at times).


TextPad has a similar feature but they seem to use the Glue method and I find it pretty annoying to use for any extended period of time.

TheQwerty wrote:I think we really have three options (which I think you've all mentioned already). To make this a little easier let's consider how the top item in each pane is connected when enabling synchronization.

1) Chained: 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.

2) Glue: The alignment pulls apart when scrolling to ensure the "shorter" pane is displaying content. However, the items are still sticky, so when the user changes direction each pane resumes scrolling at that point. The original alignment is lost and replace with the alignment that was in place when the user changes direction.

3) Magnetic: The alignment pulls apart when scrolling to ensure the "shorter" pane is displaying content, like Glue. However, the items don't re-align when the user changes direction, instead the pane will resume scrolling when the original alignment is restored.


Personally, I'd prefer the magnetic option, as my main goal would be to establish alignment and keep it, but think the empty panes in the chained method would be confusing (and even a little annoying at times).


TextPad has a similar feature but they seem to use the Glue method and I find it pretty annoying to use for any extended period of time.

Nice description. If these are the standards then i would prefer the "Magnetic" method but still would want some indication on the shorter list that its not synced with the one i am scrolling away. maybe only the last row in shorter list gets blank, indicating there nothing below it?