View Issue Details

IDProjectCategoryView StatusLast Update
0017810MediaMonkey 5Main Panelpublic2021-09-17 15:12
ReporterLudek Assigned To 
Status closedResolutionreopened 
Product Version5.0 
Target Version5.0.2Fixed in Version5.0.2 
Summary0017810: User is not aware how to enable power scroll on Media Tree (like in MM4)
DescriptionCurrently the power scroll works on Media Tree only with the '[x] Show all subnodes' option enabled (from the hamburger menu of the Media tree).

The rationale is that if someone uses all the subnodes (like all individual artists) then the power scroll in the media tree is welcome.
But if you focus Music > Artists in the media tree without all the subnodes enabled (default config) then typing rather performs the filtering in the Artist grid (on the right) as more desirable/useful action (than making the power scroll on the 'Media Tree' without the subnodes)

On the other hand (as reported by Barry here: ) there are situations where power scroll on the Media Tree is welcome even when '[ ] Show all subnodes' is disabled (e.g. in sub-folders sub to the Folders node)

Possible solutions:
a) add separate config for enabling power scroll in the Media Tree (to its hamburger menu)
b) enable power scroll automatically whenever the focused node in the Media Tree have at least 50 siblings ?
c) any other idea ?

Solution a) requires a new string, but is probably cleanest ?
b) might be useful, but looks tricky and might be considered rather as a bug to have such a inconsistent behaviour ?

Additional Information
Fixed in build2503


related to 0013223 feedbackrusty Means of browsing tree content even if the tree is collapsed 
related to 0017969 feedbackpeke Global search: Global Search do not respect Selected collection 
related to 0018272 closedLudek 'Show all subnodes' enabled by default 



2021-05-20 17:22

administrator   ~0063327

Considering that Powerscroll is always active when Playing is in focus (in fact, it seems to be expected behavior), one could argue that it should similarly be active when the Tree is in focus (and that contextual search should only apply when the breadcrumb bar or main panel are in focus).

With that in mind would it make sense that Powerscroll is active in the tree whenever Keyboard Focus is active in the tree (i.e. when the highlighted tree element has the dashed line around it--this occurs after the user has used the arrow keys in the tree thereby activating Keyboard Navigation/Powerscroll)?

And when the user just clicks a tree node with the mouse, 'Keyboard focus' isn't active in the tree, so typing would activate contextual search.


2021-05-20 18:14

developer   ~0063329

ok, sounds good, so let's implement this way and collect feedback


2021-05-20 21:12

developer   ~0063341

Seems to work fine as suggested by Rusty

Implemented in build 2406


2021-05-21 22:01

developer   ~0063376

Last edited: 2021-05-21 22:02

View 2 revisions

Confirmed on 2406, powerscroll works after using keyboard in Media Tree.

However in Playing a mouse click activates powerscroll whereas in the Media Tree it doesn't. It seems to me that powerscroll should also be active in the Media Tree when focus is shifted to it by mouse click.


2021-05-21 22:09

administrator   ~0063379

I think that the current implementation strikes a better balance as it allows the user to use contextual search when they click a node. e.g. click Video and then type 'Star Wars'. Resolving for now.


2021-05-24 09:17

developer   ~0063411

I also think that current implementation is fine, but there is already some negative feedback about the change here:
and here by Barry:


2021-05-24 09:30

administrator   ~0063413

I think that a) would be cleanest, as in other cases it's just a guess of what user really wants, which often results in complaints.


2021-05-24 09:51

developer   ~0063414

I would like to avoid adding another option as this option would be hard to find, hard to understand and would require new strings to translate/localize --- and probably would be even harder to think about a name for such an option.

I must finally admit that the cleanest solution is to always perform the search on the Media Tree if it has focus, so both clicking a node in Media Tree and keyboard navigation would perform search within the Media Tree (until 'Tab' key is used to change focus to the grid/list). Thoughs?


2021-05-24 15:26

administrator   ~0063415

I agree with Ludek re. not adding another config entry for a really hard to explain concept.

Ludek's solution seems reasonable, though I prefer Barry's slightly different suggestion:
- When show all subnodes is enabled, use powerscroll in the tree anytime focus rests in the tree (same as Ludek suggested)
- When show all subnodes is disabled, retain the current approach OR always enable powerscroll when focus is on hierarchical nodes (Playlists, Folders, Locations)


2021-05-24 15:56

developer   ~0063417

OK, fixed in 2408

- When show all subnodes is enabled, use powerscroll in the tree anytime focus rests in the tree
- When show all subnodes is disabled, retain the current approach


2021-05-27 17:24

developer   ~0063550

Verified it works as implemented on 2408

However, this still is strange when using the Location sub-node. I'd always consider mouse click a focus on tree and use powerscroll regardless if mouse or keyboard is used and regardless of Media Tree settings. The current implementation is inconsistent.


2021-05-27 22:08

administrator   ~0063572

Are you suggesting that when 'show all subnodes' is disabled, that the second approach is preferable i.e.: Never enable powerscroll except "...... always enable powerscroll when focus is on hierarchical nodes (Playlists, Folders, Locations)"

Downsides of the proposed change:
- It's still not totally consistent (though it's more consistent)
- Powerscroll isn't available for most nodes unless 'Show all nodes' is enabled (a minor issue, I think)

Leaving to Ludek to triage.


2021-05-28 07:02

administrator   ~0063581

I'm afraid that it'd be even worse - just imagine using powerscroll from one node and than moving to another node => powerscroll suddenly doesn't work.

I think that the real consistency can only be achieved by a new option -- suggested as a). Or, if we don't want to introduce a new option (at least not for 5.0.1, possibly for 5.1), I'd just return to the original implementation.


2021-05-28 08:33

developer   ~0063583

Last edited: 2021-05-28 08:51

View 2 revisions

I think that based on the current feedback the Rusty's "second approach" will mostly work fine for eveyone:
 'show all subnodes' is enabled: Always perform power scroll
 'show all subnodes' is disabled: Always enable powerscroll when focus is on hierarchical nodes (Playlists, Folders, Locations)

i.e. this way clicking 'Video' collection and typing 'Star Wars' will filter view to Star War's videos (instead of searching for 'Star Wars' node in collapsed media tree)


2021-05-28 08:43

administrator   ~0063584

Last edited: 2021-05-28 08:44

View 2 revisions

To better explain why I think this is even worse:

1. Imagine you are in an expanded Folders node and start typing some letters => MM starts focusing found nodes as expected (per configuration).
2. However, due to a typo or simply because it starts by the typed letters, you get e.g. Music or Artists node focused.
3. You realize you'd like to find something else, start typing => nothing happens!

That's why I think we should either have a dedicated option, or infer user's intention from the existing Show All Subnodes option. In other words, I think that the tree either should always support power search or never, anything in between will cause troubles.


2021-05-28 09:04

developer   ~0063585

Last edited: 2021-05-28 09:09

View 3 revisions

ok, trying to implement the approach suggested by LowLander and Rusty and actually it is indeed even worse, not only for the case mentioned by Jiri above, but also for cases when e.g. Pinned node is expanded and some of the pinned items are folders and other items are artists, then clicking Pinned > MyFolder results in power-scroll while clicking Pinned > Artist1 results in view filtering.

So we should perform power-scroll whenever the tree has a focus (or never).
Assigned to Rusty to review wording of the new option -- if we do not want to add this option then assign back to me to change current approach to always perform power-scroll within the tree.


2021-05-28 13:23

administrator   ~0063591

Re. the objection that Jiri raised at point 2. at 0017810:0063584:
Can't this be resolved quite simply by having Powerscroll work only within the nodes in which it's enabled?


2021-06-03 16:09

administrator   ~0063713

I don't think it helps much. I mean, it resolves the particular issue described, but I still think that the resulting inconsistency would be much worse than adding a new option. I suppose that there'd still be enough confusion re. why something can be searched for and something not. Not mentioning corner cases like custom nodes - we'd have to resolve whether such nodes are/aren't part of Power Search. Instead of all this, I'd say that an option like "[x] Quicksearch in Tree" would make everyone happy.


2021-06-21 10:42

developer   ~0064034

Last edited: 2021-06-21 10:42

View 2 revisions

Another objection is (details in 0017969 ) that currently (with [x] Show all nodes enabled) user is not aware how to search within the collection (because power scroll on Media Tree is performed instead).


2021-09-15 09:36

developer   ~0064639

Last edited: 2021-09-15 18:36

View 3 revisions

a) I think that better name than "quick search" would be
[..] Scroll to match when typing in tree

As for the default: I would suggest to disable this by default, but keep it enabled for those users that already manually activated 'Show all subnodes' in the previous versions (to prevent from complaints re behaviour change).


2021-09-17 06:11

administrator   ~0064714

Makes sense to me this way.


2021-09-17 10:18

developer   ~0064719

Fixed in 2503

i.e. added 'Scroll to match when typing in tree' with the default suggested in my last note.


2021-09-17 15:12

developer   ~0064726

Verified on 2503 that scroll to match has been implemented as an option and works as expected