Scrolling vs Back/Forward -- pane-dependent?

[zer0]

I notice that, when using my mouse's -- Logitech MX400 Laser -- scroll-wheel and back/forward buttons, the behaviour seems to differ depending which pane the cursor is over.

For example, if a cursor is over a list of a tab in the inactive pane then (horizontal/vertical, as applicable) scrolling is actioned on that tab (even though it's inactive). However, back/forward buttons -- as featured on many mice these days -- are still actioned on an opened tab in the active pane regardless of the cursor's position.

This behaviour seems inconsistent and, having got a whole lot of nada from the forum/changelog searches, prompted this query -- why is it the way it is?

[admin]

Technical reasons: Scrolling is easily done on the inactive tab. But changing the location not so -- it is "inactive" after all. It would take extra measures by me to make this happen which I not have taken for these special buttons.

So this is turned into a wish (I assume), but I can't give it high priority I'm afraid.

[zer0]

Technical reasons: Scrolling is easily done on the inactive tab. But changing the location not so -- it is "inactive" after all. It would take extra measures by me to make this happen which I not have taken for these special buttons.

So this is turned into a wish (I assume), but I can't give it high priority I'm afraid.

I'd rather scrolling and changing location is done in the active tab regardless of (x,y) of the cursor as it shouldn't dictate the behaviour it doesn't not directly trigger. Would it be easier to transplant scrolling from inactive to active tab as opposed to enable change of location for the inactive tab?

[TheQwerty]

I'd rather scrolling and changing location is done in the active tab regardless of (x,y) of the cursor as it shouldn't dictate the behaviour it doesn't not directly trigger. Would it be easier to transplant scrolling from inactive to active tab as opposed to enable change of location for the inactive tab?

Yeah, not that I'd use it because I like being able to scroll there, but I don't think the Back/Forward should ever work for inactive panes.

In other words, if you change anything here it should be an option/tweak to disallow scrolling the inactive pane.

[admin]

I'd rather scrolling and changing location is done in the active tab regardless of (x,y) of the cursor as it shouldn't dictate the behaviour it doesn't not directly trigger. Would it be easier to transplant scrolling from inactive to active tab as opposed to enable change of location for the inactive tab?

Yeah, not that I'd use it because I like being able to scroll there, but I don't think the Back/Forward should ever work for inactive panes.

In other words, if you change anything here it should be an option/tweak to disallow scrolling the inactive pane.

I see no reason to change scrolling the inactive pane. Hey, I use it all the time! It's inactive, not disabled.

[PeterH]

I see no reason to change scrolling the inactive pane. Hey, I use it all the time! It's inactive, not disabled.

Exactly: to select which pane to scroll by moving the cursor over that pane is *very* good! It would be bad if it were necessary to activate a pane just to scroll it, and then to activate the other again...
(Same for tree...)

[TheQwerty]

I was not, nor was zer0 I believe, suggesting that THE behavior be that you can only scroll the active pane.

When Don claimed this could become a wish zer0 and myself were simply saying that the wish is NOT that back/forward works on the inactive but hovered tab. Rather the wish, if there is one, is for an option/tweak that disabled the ability to scroll the inactive tab.

It's great that both of you, and myself as well, like to scroll the inactive tab, but zer0 and presumably someone else may find it confusing and inconsistent.

[zer0]

It's great that both of you, and myself as well, like to scroll the inactive tab, but zer0 and presumably someone else may find it confusing and inconsistent.

Quite well said, TheQwerty! I am firmly of an opinion that there must be consistency with respect to behaviour that is actioned via a mouse. Having such a discrepancy confused me, hence this query.

A tweak to clear things up can be called PanesScrollwheelBehaviour with the following parameters:
0 = default // how it is now
1 = only active pane // without needing to mouseover

Since this is a discussion about panes, I didn't include the navigation panel, but if someone would like for that area to be different then please speak up

[admin]

Allow me to wait until a more impressive crowd gathers that is confused by the fact that you can scroll the inactive pane.

[PeterH]

It's great that both of you, and myself as well, like to scroll the inactive tab, but zer0 and presumably someone else may find it confusing and inconsistent.

Quite well said, TheQwerty! I am firmly of an opinion that there must be consistency with respect to behaviour that is actioned via a mouse. Having such a discrepancy confused me, hence this query.

A tweak to clear things up can be called PanesScrollwheelBehaviour with the following parameters:
0 = default // how it is now
1 = only active pane // without needing to mouseover

Since this is a discussion about panes, I didn't include the navigation panel, but if someone would like for that area to be different then please speak up

Don't get me wrong: no offense meant in the following...

It seems to be so that what people (incl. me) are expecting is just different. So my point of view in some words...
...and these words even include "other panels":

When list is active I like to scroll the tree by just hovering over it.
Still more for the opposite.

For an active preview possibly showing a list of files I like to scroll the (inactive) list - and vice versa.
And for me it would be very strange ("inconsistent"?) if this would not be possible on inactive (list-)pane, too.

All this was reason for me to say that Don's statement is right (for me) - and from this position I can't understand some other thinking. But that doesn't mean it's wrong - it only means that it's wrong for my kind of thinking...

However I understand, that other mouse keys may have functions *not* appropriate for the inactive list. But I think the same is right for some keys on keyboard?

[zer0]

Allow me to wait until a more impressive crowd gathers that is confused by the fact that you can scroll the inactive pane.

If you see it as a wish, then fair enough. I see it more of a return to a consistent state, which means this predicament has a whiff of a bug and thus does not require every man and a dog turning up in its support

Don't get me wrong: no offense meant in the following...

It seems to be so that what people (incl. me) are expecting is just different. So my point of view in some words...
...and these words even include "other panels":

When list is active I like to scroll the tree by just hovering over it.
Still more for the opposite.

For an active preview possibly showing a list of files I like to scroll the (inactive) list - and vice versa.
And for me it would be very strange ("inconsistent"?) if this would not be possible on inactive (list-)pane, too.

All this was reason for me to say that Don's statement is right (for me) - and from this position I can't understand some other thinking. But that doesn't mean it's wrong - it only means that it's wrong for my kind of thinking...

However I understand, that other mouse keys may have functions *not* appropriate for the inactive list. But I think the same is right for some keys on keyboard?

It's fine, no offence taken. I just find it confusing how less-essential-than-scroll-wheel back/forward buttons are working within the context of the active tab without the need of a mouseover over that tab's contents. Considering that I run a multiple monitor setup, having a mouse over a specific area just for the purposes of scrolling adds extra effort. With back/forward, all I need to do is make sure that XYplorer's window is active.

[PeterH]

It's fine, no offence taken. I just find it confusing how less-essential-than-scroll-wheel back/forward buttons are working within the context of the active tab without the need of a mouseover over that tab's contents. Considering that I run a multiple monitor setup, having a mouse over a specific area just for the purposes of scrolling adds extra effort. With back/forward, all I need to do is make sure that XYplorer's window is active.

If I understand it correct, you think it's bad if you must have mouse over active pane to scroll it, while I think it's bad if I must activate the inactive pane to scroll it, and then must (re-)activate the former active pane again.
I'm afraid you have as much problems to understand my expectations, as I have with yours...

If Don should see it this way he might add a tweak to change to your wish. (I'm on the green side of life this time - as I happen to share his thinking for this case. )

But: do you think it's good that cursor over tree scrolls tree, and cursor over list scrolls list? Or do you even dislike that?
Now just testing my next statement I found a bug??? Show a long .txt-file in preview and cursor over it scrolls just the preview (=OK for me!) *but* then move cursor over anything else (tree or list) scrolls that area, but *also* scrolls preview! (I.e. preview is always scrolled )

[admin]

Now just testing my next statement I found a bug??? Show a long .txt-file in preview and cursor over it scrolls just the preview (=OK for me!) *but* then move cursor over anything else (tree or list) scrolls that area, but *also* scrolls preview! (I.e. preview is always scrolled )

Indeed, over here the text preview scrolls one notch when you wheel-scroll any other element in the main window, but only if you scroll the text preview using the scroll bar at least one time. I'm afraid I have no influence over this. This scrolling is not mine but completely owned by Windows.

[zer0]

If I understand it correct, you think it's bad if you must have mouse over active pane to scroll it, while I think it's bad if I must activate the inactive pane to scroll it, and then must (re-)activate the former active pane again.
I'm afraid you have as much problems to understand my expectations, as I have with yours...

I am simply of an opinion that if a pane is inactive then mouseover-sensitive actions shouldn't apply to it. I have 2 big monitors, the mouse cursor is small. It's easier for to me to determine that XYplorer's window is active than make sure that the cursor is over the active pane. Its size could be small, so that would make acquiring it would make it that much trickier.

[PeterH]

If I understand it correct, you think it's bad if you must have mouse over active pane to scroll it, while I think it's bad if I must activate the inactive pane to scroll it, and then must (re-)activate the former active pane again.
I'm afraid you have as much problems to understand my expectations, as I have with yours...

I am simply of an opinion that if a pane is inactive then mouseover-sensitive actions shouldn't apply to it. I have 2 big monitors, the mouse cursor is small. It's easier for to me to determine that XYplorer's window is active than make sure that the cursor is over the active pane. Its size could be small, so that would make acquiring it would make it that much trickier.

But you don't say anything to the point that mouse *must* be over tree to scroll tree, and over list to scroll list? That is: you *must* position the mouse to scroll what you want?