Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[audioriver]

Options/Tree & View/Tree/Auto expand is unchecked

However, when clicking on either of my two Playing Now tabs (locked tabs, 2 Views Split View, Rows) then the Playing Now section on top of the Tree will always expand. Is this to be expected? (or expanded, if you will...)

I would hope it wouldn't expand.

[HPBEME]

I would hope it wouldn't expand.

I agree, but that is how it behaves for me as well.  For me at least, it expands tree nodes for any tab I select, whether the customized view is for audio, video, or images (i.e., not just playing now tabs). Basically, unchecking this setting seems to have no effect on stopping tree nodes from auto-expanding.

I personally keep auto-expand box checked, since at least it collapses other tree nodes when you click on a different node/tab - at least most of the time.  I often end up having to manually collapse various tree nodes due to the inconsistent auto-expand/collapse behavior. 

Closely related is the hotkey Ctrl+G to Collapse All tree nodes, which is a fantastic tool but is also inconsistent.  Sometimes it will only collapse a single sub-node, requiring several hotkey launches in order to collapse everything. Other times, it collapses a tree node but simultaneously expands the Playing Now node.

These are long-standing MC bugs I would love to see wrangled.

[audioriver]

This would be the perfect time for MC people to chime in, letting us know whether we can expect some solutions in MC31, or at least MC32.

[Matt]

Playing Now tabs are zones underneath the playing now root item.  So selecting them is going to expand so you can actually see the item.

[audioriver]

Playing Now tabs are zones underneath the playing now root item.  So selecting them is going to expand so you can actually see the item.

Even when there is a clear option set to NOT auto expand anything in Tree?

[Matt]

Even when there is a clear option set to NOT auto expand anything in Tree?

That option determines whether clicking on a tree item expands it.

[audioriver]

You are right, even though I don't understand it. It doesn't matter whether I click on the little arrow to the right, or on "Playlists" for example. Playlists will expand on both cases (option is disabled).

In any case and unrelated to the above Playlists remark: please consider adding an option to never auto-expand anything in the Tree, unless of course the user explicitly asks for it, by clicking in the Tree. The goal here is for MC to always remember, maintain and start up with a user-defined selection of both expanded and unexpanded Tree items, without having them expanding and collapsing on their own.

And by "on their own" I mean, usage of MC outside the left Tree area. Thanks.

[Dawgincontrol]

You are right, even though I don't understand it. It doesn't matter whether I click on the little arrow to the right, or on "Playlists" for example. Playlists will expand on both cases (option is disabled).

In any case and unrelated to the above Playlists remark: please consider adding an option to never auto-expand anything in the Tree, unless of course the user explicitly asks for it, by clicking in the Tree. The goal here is for MC to always remember, maintain and start up with a user-defined selection of both expanded and unexpanded Tree items, without having them expanding and collapsing on their own.

And by "on their own" I mean, usage of MC outside the left Tree area. Thanks.

Been asking for similar for years, but you're dealing with programmers.   

[HPBEME]

I hope the inconsistent behavior of auto–expand/collapse I described in my post above will still be evaluated... as well as the hotkey CTRL+G (collapse all tree nodes) jankyness. 

I generally like how the tree/tab work together, it is the inconsistency that is an issue.  In particular, the Playing Now tree node wants to expand itself all the time, even when nothing is driving it to do so (forcing a manual collapse).

[Matt]

Closely related is the hotkey Ctrl+G to Collapse All tree nodes, which is a fantastic tool but is also inconsistent.  Sometimes it will only collapse a single sub-node, requiring several hotkey launches in order to collapse everything. Other times, it collapses a tree node but simultaneously expands the Playing Now node.

It was saving the expanded items, collapsing, then restoring the expanded items next time.

I'm going to change v32 to simply always collapse.

Thanks.

[HPBEME]

Perfect.  Thank you Matt.

[HPBEME]

Since you're going to make this a v32 implementation, I guess I should have also noted that tree nodes for Streaming, Explorer (under Drives & Devices), and Services & Plug-ins remain fully expanded after selecting a new tree node or tab, forcing the user to manually collapse those items.  You may also want to take a look at split views and how those behave with respect to this setting.

[markf2748]

It was saving the expanded items, collapsing, then restoring the expanded items next time.

Not quite what I see for <CTRL><g>, so I'm a little confused by this statement.  Here's what I see with Tree & View > Tree > [ ] Auto expand unchecked:

1) If tree is collapsed completely, then <CTRL><g> expands all branches completely.
2) If tree is expanded completely, then <CTRL><g> collapses all branches completely.
3) If tree is partially expanded, then <CTRL><g> expands all branches.  Applied again it collapses all branches.  Applied again it expands all, etc. cycling between 1) and 2).

This pattern is consistent, but not very useful for me since there is no restore of my previously selected subset of expanded branches. 

I would greatly prefer:
1)  <CTRL><g> does have memory of my expanded branches, and cycles directly between Collapse All / Expand Subset, i.e. expands (restores) just the subset which I had previously expanded.   From a fully expanded state, it traverses to Expand Subset (if it exists), and then to Collapse All.
2) Implement <CTRL><SHIFT><g> to directly Expand All branches / Collapse All branches.
3) User creates a new "restorable" subset by modifying any of: the fully collapsed state, the fully expanded state, or the previous restorable subset.  From a new restorable state, <CTRL><g> naturally goes to Collapse All.

I find <CTRL><g> has no affect on branches in the Tags Tree.  It would make logical sense for it to have the same set of collapse/expand actions in the Tag Tree as it does in the main Tree (though the RMB menu Expand All / Collapse All in any tag section header is already pretty convenient).

Since you're going to make this a v32 implementation, I guess I should have also noted that tree nodes for Streaming, Explorer (under Drives & Devices), and Services & Plug-ins remain fully expanded after selecting a new tree node or tab, forcing the user to manually collapse those items.

In this regard, I'm perfectly OK with the current "additive" and "manually close" behavior of those branches.  I do not want the tree view to change when I select a new tab, except for the highlighted line in the Tree jumping to the tab selection (and expanding the corresponding branch if necessary to see it), as it does now.

[markf2748]

Additional Tree niggle:
RMB on most branch headers reveals the top smart menu item Collapse... or Expand..., depending on current branch state.  These menu options are missing for the branches Drives & Devices and Services & Plugins.  They should be there just for consistency.

Feature request for main Tree (for MC 32?):
In each branch header RMB menu, add items Save Tree View and Restore Tree View, which would replicate the complete mix of open and closed branches.  These could open a conventional Save/Restore popup menu, or equivalent drop down menus.  Also add a keyboard shortcut for this feature.

An alternate implementation would add a small super menu box (like in upper left corner of the Tag Tree).  It would list custom main Tree views, add current view to list, delete view from list, as well as options to Collapse All branches and Expand All branches.

[markf2748]

Not quite what I see for <CTRL><g>, so I'm a little confused by this statement.  Here's what I see with Tree & View > Tree > [ ] Auto expand unchecked:

1) If tree is collapsed completely, then <CTRL><g> expands all branches completely.
2) If tree is expanded completely, then <CTRL><g> collapses all branches completely.
3) If tree is partially expanded, then <CTRL><g> expands all branches.  Applied again it collapses all branches.  Applied again it expands all, etc. cycling between 1) and 2).

This pattern is consistent, but not very useful for me since there is no restore of my previously selected subset of expanded branches. 

I would greatly prefer:
1)  <CTRL><g> does have memory of my expanded branches, and cycles directly between Collapse All / Expand Subset, i.e. expands (restores) just the subset which I had previously expanded.   From a fully expanded state, it traverses to Expand Subset (if it exists), and then to Collapse All.
2) Implement <CTRL><SHIFT><g> to directly Expand All branches / Collapse All branches.
3) User creates a new "restorable" subset by modifying any of: the fully collapsed state, the fully expanded state, or the previous restorable subset.  From a new restorable state, <CTRL><g> naturally goes to Collapse All.

Suddenly today <CTRL><g> does have memory, and directly cycles between Collapse All / Expand Subset, as preferred.  Previously it behaved repeatedly as if the tree view memory for <CTRL><g> was stuck on "all expanded" instead of updating to my actually expanded branches.  Something wonky was going on.  AFAIK, the only thing I changed since previously reported behavior is I ripped a CD and added to library as usual. 

Win 11 Pro 23H2 64-bit   MC 31.0.87

[markf2748]

OK, so here is how <CTRL><g> really works for me:

1) For clarity in this demonstration, collapse all tree branches.  Verify that <CTRL><g> leaves all branches collapsed.
2) Expand one or more branches. 
3) Now <CTRL><g> nicely cycles between "all collapsed" and the tree view as just expanded in 2).
4) While "all collapsed", create a new tree view by expanding another set of branches. 
5) Now <CTRL><g> continues to cycle between tree view 2) and "all collapsed".  It does not remember the new state 4) !
6) In order to update the <CTRL><g> tree view memory, you must modify branches while "cycled" into state 2), or else start from 1).

This description fully explains both of my detailed cases described above.  I obviously found it could be quite confusing, until I finally deciphered the pattern.

It might be more intuitive if the <CTRL><g> tree view memory updates itself from step 4), as well as when cycled into state 2).  In any case, the behavior needs to be explained with a tooltip and/or in the wiki's Keyboard Hot-keys section.