View Issue Details

IDProjectCategoryView StatusLast Update
0015926MediaMonkey 5Tracklistpublic2020-02-19 03:31
Status closedResolutionreopened 
Product Version5.0 
Target Version5.0Fixed in Version5.0 
Summary0015926: Improvements to navigation of Playlist/Folder hierarchy
DescriptionIn 0015712, Ludek wrote that:
"Users are confused by the "Playlist grid" sub-view, see details here:
I guess we should rename it to "Sub-playlists" ?
Similarly "Folders" should be renamed to "Sub-folders" in the location tree."

I've opened this bug since the confusion stems from more than a wording issue:

Currently, navigation of Playlist hierarchy and Folders ('containers') is fine in the tree, but poor when it comes to the tracklist. The issues are:
1) Grid views are limiting in the sense that:
. i) they take up too much space thereby requiring a lot of scrolling to get to actual files in the view
. ii) they truncate important metadata

2) List views to deal with the above have been implemented via an independent tree, but it's a limited implementation:
. i) currently, the 'Playlist tree' subview is only implemented for Playlists but not for Locations/Folders
. ii) the current implementation addresses the need to navigate the hierarchy, but it replicates the Grid view. e.g.
. . . 1 Navigate to Playlists
. . . 2 Enable Playlist tree subview
. . . --> All playlists appear in duplicate (once in the Playlist Tree and once in the Grid)!
. iii) the current implementation doesn't inherit parent container settings causing view settings to change as the user navigates playlists! e.g.
. . . 3 Click the 'Imported Playlists' node in the Playlists Tree
. . . --> The Playlist Tree disappears!!
. . . . Similarly, a situation could arise in which the tree is enabled in the Playlists node, and the user navigates to a subplaylist but no Grid/List displays!!

Issue 1) can be alleviated by enabling 'List' views in addition to Grids for containers, so that containers can be displayed one per row, with metadata of the users choice (much like most file explorers). I'm not sure if this is feasible for 5.0, and may not be critical if issue 2) is fixed sufficiently. Note, however, that I believe that a List view should be the default.

Issue 2) can be resolved as follows:
a) Use x sets of heritable settings for Playlists, so that whatever the user configures for the root Playlists node applies to child nodes as well. e.g.
. i) For the Playlist root, offer view choices of:
. . - Grid: Subview configured in 'Manage views', no flags (Playlist as thumbnails, Metadata: Playlist name)
. . - Tree: Subview configured in 'Manage views', no flags (Playlist in tree)
. . - List: Subview configured in 'Manage views', no flags (Playlists in list, Metadata: thumbnail, Playlist name, #Tracks, Last edited)

. ii) For an individual Playlist (whether a Playlist or container), remove the choice of Playlists Tree/Playlists Grid as subviews, and instead create a separate section below subviews:
. . Show Playlists as
. . (o) Grid
. . ( ) Tree
. . ( ) List

If the user makes a change here, then it should apply to the Playlist root node as well.

. iii) A similar approach should be used for Locations/Folders
TagsNo tags attached.
Fixed in build2228


related to 0015712 resolvedrusty "Art View", "Browser View", "Grid View" - why different names for the same view 
related to 0015584 closedpetr Views: Subviews should persist on a per-view basis 
related to 0015756 feedbackrusty 'Manage views' functionality seems broken / incomplete 
related to 0016065 assignedpetr Context menu cleanup 
related to 0016204 closedLudek Playlists list is not scrollable in the List view 
related to 0016266 resolvedLudek "Grid (by Album)" view is missing from some views 
related to 0016360 closedLudek Status bar issues 
related to 0016350 closedpetr It is unclear what half-checked state for a collection/node means + wording changes 
related to 0016364 new Options: views for certain nodes can't be configured 



2019-09-09 10:57

developer   ~0054554

I don't think that having the restriction of showing only single playlist view type is a good restriction.
e.g. with 'media tree' disabled and 'playlist tree' enabled like this:

Show Playlists as
. . ( ) Grid
. . (o) Tree
. . ( ) List

user would end up with this:
which is strange as it looks like the "Imported playlists" on the right has no sub-playlist, but it actually has many!

So I guess that rather the grid should be always enabled (as is by default) to show the sub-playlists.
As for the grid taking much space -- this is general issue for album/artist grids too, and can be resolved by descreasing the image size, this is already configurable in the album/artists grids and the config should be added to the others grids as well ? Also, we might want to decrease the default image size?

Also, I think that in 99% of cases the playlist either contains files or sub-playlists, there probably aren't playlists having mix of files+sub-playlists (unlike folders).
So the issues that you mentioned above are rather related to location/folders.

Assigned to Jiri to review/prioritize.


2019-09-09 17:02

administrator   ~0054565

I agree that the 'Tree' approach isn't the best (because it either results in duplication of containers as currently implemented OR no containers displayed in the tracklist as in MM4)--the only reason I left it is because it's the approach used in MM4 and some users may want to continue with that approach.

As to the need for a 'List' view that supports both folders and files: it's needed for the same reason that almost every file manager/explorer supports such a list view by default: because it allows the user to see most of the information that they want to see in relatively compact form. It's true that the need for this functionality is stronger for Locations/Folders, but given the _number_ of playlists that are displayed on my screen, I also find that playlist navigation would benefit from a list view (that displayed containers).


2019-09-23 12:56

administrator   ~0054797

Per IM discussion with the devs, the best solution treating the problems, while being feasible to implement:

S1. Show sub-playlists as a list, instead of a grid.
S2. Rename Subviews 'Playlists grid' menu item to 'Sub-playlists' (or something better?)
S3. Add a new View type 'Grid', which would show every track as a grid item (as currently Albums or Artists are) and together with this choice, also sub-playlists would be shown in a grid (as they currently are, until we change the default to a list).

Possible future changes (past 5.0):

O1. Currently we have containers (sub-playlists) and items (tracks) in two separate lists/grids, that while scrolling together, work to some degree independently. We might consider their merge into a single entity. This doesn't make sense for 5.0 though, due to complexity and risk of regressions.


2019-09-24 10:09

administrator   ~0054826

re. S1. This item actually doesn't cover the differences of the root Playlists and individual playlists nodes. Will add S4 to cover this.
re. S2. Ok, will hopefully be enough to understand it.
re. S3. The questions are mostly related to S4. below:

S4. The root Playlists and individual playlist should share their view configuration, e.g. Playlist tree visibility should no longer be independent between there two. The only differences are that the root Playlists node won't show 'Column filter', 'Info panel' and probably also 'Status bar' (even though, it possibly could be there). It will also show Playlists, regardless of '[ ] Playlists' (S2) configuration. It also probably doesn't need to show 'List (by Album)' view type, since it would result in the very same view as simple 'List'.

Since these changes all seem to be in agreement with what Rusty wanted to change and should be mostly quite easy to implement, assigning to Michal (in cooperation with Ludek), so that we can have some preview of the changes and can better discuss them in a less abstract manner.


2019-10-02 09:15

developer   ~0054911

Implemented in 2203


2019-10-04 05:13

administrator   ~0054928

Last edited: 2019-10-04 19:36

View 4 revisions (I apologize in advance for the length--no need to watch any of it unless something below is unclear--it's probably most useful for 2)/S4 and 7a.

2)/S4 [high level issue]
The current implementation uses the same view for both containers and tracks. This isn't at all what I was trying to suggest. I was trying to suggest that subviews for nodes and tracks should be configurable independently, and heritable independently. The current implemntation results in:
- Grid view is unusable anywhere other than the root node (see 6a below)
- As a consequence of the above, nodes display differently from one node to the other (e.g. Playlists display as icons in the root, but as list items in other nodes)

3) Playlists [List view]:

a) there's no indication of which entries are containers (no arrow/indentation)!

b) enable Playlist Tree
--> Playlist tree appears with all entries truncated!
Note: I CANNOT REPLICATE THIS any longer--I'm not sure what the trigger was, but probably related to 7a.

4) Playlist>PlaylistName [List]: Switch from Grid > List > List by Album > Grid > List >
--> List appears empty!
Note: I CANNOT REPLICATE THIS any longer--I'm not sure what the trigger was.

5) Playlist>PlaylistName [List by Album]:

a) Tracks don't display in the order of the Playlist!
1 Change the sort order so that they display in the correct order
2 Switch nodes and then back to the original nodes
--> Tracks again don't display in the correct order (the sort order wasn't saved)!

1 Navigate to Playlist>PlaylistContainer>PlaylistName
2 Navigate to a different Playlist>PlaylistName
--> List appears empty (user has to scroll halfway down the screen to see the list) and only 1-2 tracks display at any one time!
Note: I CANNOT REPLICATE THIS any longer--I'm not sure what the trigger was but possibly related to 7a.

c) For both Playlists and Locations, in List by Album view, when scrolling downwards MM often resets the view to the top by itself. See:

d) In the Locations node, if the user enables List by Album view when 'display folder content recursively' is enabled, then the button to disable recursive mode disappears (it's overwritten by the 'Collapse albums' button.

6) Playlist>PlaylistName [Grid]
a) this view doesn't make sense for tracklists (it only makes sense for tracklist containers)! This is because it's unclear that the albums represent tracks and not albums;
b) This is a moot point assuming we fix the above issue, but the albums don't display in the correct order and there's no way to sort them in the correct order

7) With Playlist Tree enabled:

a) View gets corrupted sometimes (this is most likely the cause of the various other issues that I'm having trouble replicating). I'm not sure of the exact cause, but it seems to be related to enabling the PlaylistTree and then navigating among nested playlists between both the tree and the list view. After doing so:
Navigating to Playlist>PlaylistContainer>PlaylistName
--> Multiple lines of text are superimposed upon one another just above the header bar
See at around 9:00-11:00 in the video
Associated debug log is attached.

b) Selection of an item in the tree can fail
1 Select PlaylistA in the PlaylistTree
--> Tracklist updates as expected
2 Select Playlists in the main tree
--> Tracklist updates as expected
3 Select PlaylistA in the PlaylistTree
--> Nothing happens!

c) Playlist selection can cause the tree in PlaylistTree to collapse
1 In Playlist tree, select PlaylistContainer>PlaylistNameA
2 In List view, select PlaylistNameB
--> PlaylistContainer collapses

d) Playlists>PlaylistContainer>PlaylistName [List by Album] displays incorrectly (similar to the above but worse than without PlaylistTree enabled)
(tested with Playlists>Event playlists>Channuka dinner)
--> List appears empty (user has to scroll halfway down the screen to see the list)
--> On scrolling, the header gets 'stuck' in the middle of the screen as tracks scroll through it
Note: I CANNOT REPLICATE THIS any longer--I'm not sure what the trigger was but probably related to 7a.

EDIT: I've added items 5c),d)


2019-10-04 05:14


bug15926_item7a.7z (137,684 bytes)


2019-10-04 09:19

developer   ~0054941

Last edited: 2019-10-04 09:27

View 4 revisions

ok, besides all the mentioned sub-issues above (where most of them are long-standing or Rusty can no longer replicate) there remains the main question that needs to be decided:

6a) Rusty thinks that representing both tracks and containers in a grid doesn't make sense (while Jiri thinks it is useful -- e.g. for touch mode)

Assigned to Jiri for triage / review of the Rusty's notes and the implementation in 2203


2019-10-07 12:35

administrator   ~0054962

S4. Isn't implemented yet, i.e. Playlists node and individual Playlists still have independent configuration (Ludek)

2) re. same view for both containers and tracks - makes sense to me, after all this is how e.g. Explorer works. We can discuss over IM with Rusty.

3a) Containers are somewhat differentiated by their icon. That said, we certainly could consider somewhat more prominent differentiation.

The rest seems to be mainly some UI updates problems, Ludek please have a look and let me know.


2019-10-07 17:22

developer   ~0054963

Last edited: 2019-10-14 19:29

View 10 revisions

Items 7a, 7b, S4) are fixed in 2204

EDIT: 7a) still isn't fully fixed, it still happens sometimes, finding more...
EDIT2: S4) also isn't fully fixed for root location/folders nodes

3a) I added the children count info directly like:
[icon] Imported Playlists (226 playlists)

=> fixed in 2205


2019-10-16 10:07

developer   ~0055018

Last edited: 2019-10-17 09:41

View 6 revisions

Re-opened: I forgot to fix items 5a & 5d

=> 5d is fixed in 2205
=> 5a to be fixed by Petr (details sent over IM)

S4) is implemented in 2205, but I suppose that the default view type "list" versus "grid" should vary based on the mode "Desktop" versus "Touch" ?
e.g. 'Folders' node in the Desktop mode would default to list:
While the same "Folders" node in the Touch mode defaults to grid:

2/S4) I am not sure whether the "grid" vs "list" should really persist for whole navigation branch, this is not how explorer works.
In Windows Explorer when you navigate C: > Temp > MP3 then you can have
- "list" in C: ( see ),
- "grid" in Temp ( see )
- "list" in MP3
And this way the view persist, so returning to C:\ is always in "list" while "C:\Temp" is always in "grid" !!

I guess that the similar could be useful in MM, e.g. for the root "Folders" node I would like to see grid (with the large icons) as there are mostly just several items, while in Folders > C: > Music > ... one would prefer "list" as the number of sub-folders is large.


2019-10-16 15:26

administrator   ~0055019

S4) re. Desktop vs. Touch defaults - sounds good to me, even though I can live without it.

2/S4) I think that in MM5 it really makes sense to keep the same view type in the whole playlist hierarchy. As for the Windows Explorer, I think that it's slightly different in this aspect - it's supposed to show very heterogeneous content, some folders contain audio, some images others documents and so it makes sense to have different views in different folders. There's rather a low need for this in MM5 imho.


2019-10-17 07:13

developer   ~0055020

5A) fixed


2019-10-17 10:39

developer   ~0055021

S4) different defaults for touch vs desktop implemented in 2205

2/S4) ok, leaving as is, i.e. keeping the same view type in the whole playlist/folder hierarchy


2019-10-18 03:39

administrator   ~0055037

Tested 2205. Verified except where indicated below:

a) Re. different defaults for Touch vs Desktop mode: sounds good. I tested it out and settings seem to persist independently as expected.
b) Re. whether the grid/list should persist down the hierarchy, it appears that they do (for both playlist containers and folders) which is fine.
c)/6 BUG: The problem still remains that Playlist tracks and containers have the same view, resulting in the situation that Grid view is only useful until the user navigates to a container that contains tracks i.e. the Grid is applied to all containers in the hierarchy (useful) and tracks (useless because it obscures track order and fails to display track metadata). I may be wrong, but I don't think that Jiri intended to include tracks as part of the 'whole hierarchy'.

3a) Containers now indicate the number of playlists contained within. Seems like a reasonable compromise.

5) Playlist>PlaylistName [List by Album]:
c) BUG: List by album view still seems to scrolls to the top by itself! e.g.
 1 switch to staticPlaylistA (containing 30 tracks)
 2 use scroll wheel to quickly scroll down 15 tracks
 --> after a second or 2, view scrolls to the top.
 Repeating step 2 causes this to happen about 4 times and then it stops occuring.

7 Playlist Tree enabled:
e) BUG: Main tree and Playlist tree can be out of sync
 1 Click Playlist A in main tree
 2 Click Playlist B in Playlist tree --> focus switches to Playlist tree as expected
 3 Click Playlist C in main tree --> focus remains on both Playlist B and C ! When the user clicks on the main tree, nothing should remain selected in the Playlist tree.
 f) Performance BUG: clicking a playlist container with many subplaylists causes the UI to not be responsive. e.g.
 1 Click Playlist: Imported Playlists (which contains many subplaylists)
 2 Immediately click Playlist B and then Playlist C and then Playlist Click
 --> UI takes about 5 seconds to respond


2019-10-18 07:44

developer   ~0055040

Last edited: 2019-10-18 08:44

View 13 revisions

c)/6) Jiri really intended to include tracks as part of the 'whole hierarchy', the point of this is that grid view is especially useful in Touch mode, but also in the Desktop mode for folders and playlists including videos, music videos and TV episodes (where the video thumbnail is the most important metadata). So I believe that the current implementation is fine in this way. Also as Jiri pointed this is how e.g. Windows Explorer works. Anyhow, user can change the grid to list anytime -- so I don't see any usability issue here.

5c) I could replicate previously, but I cannot replicate now whatever I do (following ).
Could you please catch this in debug log?

7b) I think that users will either use Media Tree or Playlist Tree, they will hardly use both -- so I don't think that this is really an issue that needs to be fixed.

7f) I cannot replicate, but maybe I am doing something differently, could you please screencast this bug with DbgView running?
Note that running DbgView can cause an UI responsiveness issue when many debug strings are about to output , but this is rather flaggy UI (than a freeze for 5 seconds).


2019-10-18 11:54

developer   ~0055042

Last edited: 2019-10-18 11:56

View 2 revisions

FYI: re 5c/7f) There were some performance issues already fixed in 2206 that could be related ( 0015971:0055041), so it would be good to test these items with 2206.
So please re-test in 2206 and screencast+debug log in case the issues still persists for you.


2019-10-18 21:20

administrator   ~0055062

S4c/6) I can understand the argument for having playlist movies display in the grid view. But when it comes to the tracks in a music playlist the grid view is useless: track representation is poor as they look like albums, metadata isn't editable in-line, and most significantly the user can't even re-order the tracks :-(

5c) Still occurring in 2206 for me. See:
Log attached.

7b) TBD

7f) Can't replicate in build build 2206.

7g) I think I mentioned this at some other point, but when the Playlist tree is enabled, and the user navigates to Playlists
--> The full list of Playlists appears twice! It looks quite strange.

build2206_group-by-album_scrolls-by-itself.7z (66,195 bytes)


2019-12-10 18:29

developer   ~0055639

Last edited: 2019-12-10 18:34

View 3 revisions

S4c/6) ok, so maybe we could resolve it by introducing third view type called "Grid/List" that would be available for playlists and folders and would achieve what you want ? i.e. folders in grid and tracks in list. I guess we could use the "browser" icon for the new view type.


2019-12-13 09:14

administrator   ~0055663

S4c/6) Sounds good to me, such a view could work fine.

8. Just a small aesthetic tweak - I'd introduce a subtle separator between the containers and tracks part. It probably could be just some 10-20px of empty space, even though a horizontal line with a low opacity in the main skin color could work too.


2019-12-16 22:05

developer   ~0055703

Last edited: 2019-12-18 14:21

View 2 revisions

S4c/6) is implemented in 2220

Lowering priority for the others items


2020-01-15 18:38

developer   ~0055887

Last edited: 2020-01-15 18:41

View 3 revisions

S4c/6) Verified 2220 in both playlists and Folders, but it looks little bit confusing and would suggest change back to just grid/list and in subviews add "Show playlists(folders) as list(grid)" depending if Grid or list is selected?

In addition to above I wonder if Folders browser would look better if Sub Folders/Playlists would be presented in Multicolumn?

bug15926_(S4c_6).jpg (101,291 bytes)
bug15926_(S4c_6).jpg (101,291 bytes)


2020-01-20 14:10

developer   ~0056032

Last edited: 2020-01-20 17:57

View 9 revisions

S4c/6) Maybe "Grid (Playlists) / List (Tracks)" would be clearer ?

Also in 0016266 we replaced 'Grid' by 'Grid (by Album)' which probably makes sense for folders (though makes less sense for playlists)

So for folders the view menu could look like this:
"Grid (Folders) / List (Tracks)"
"List (Folders) / List (Tracks)"
"List (Folders) / List (by Album)"
"Grid (Folders) / Grid (by Album)"

Thinking about it again this really is cumbersome, I guess that better is to remove "Grid/List" entirely and modify it like this:

"List (by Album)"
"Grid (by Album)"
[] Column filter
[x] Grid (Folders)
[] List (Folders)

=> Fixed in 2222


2020-01-20 18:36

administrator   ~0056039

Re. S4/6) two possible approaches:
A) If we just make wording changes, the only one that really needs to be changed is "Grid (Folders) / List (Tracks)" (i.e. the additional descriptive text for the others makes them more unwieldy).

B) A preferable approach (though I don't know if it's realistic) is to use subviews to make the View name more clear i.e. stick with Grid/List, but have the subviews indicate what subviews are enabled. Currently it shows:

[ ] Column filter
[x] Info panel
[ ] Playlist tree
[x] Playlists
[x] Status bar

Wouldn't it make more sense to display:
[ ] Column filter
[x] Info panel
[ ] Playlist tree
[x] Playlists (grid)
[x] Playlist tracks (list)
[x] Status bar

By the same token, this should be configurable within 'Manage views...' i.e.
[ ] Column filter
[x] Info panel
[ ] Playlist tree
[x] Playlists _[[grid], list]v_
[x] Status bar
[x] Playlist tracks _[[list], list (by album)]
. . . Columns: {Column Selector}


2020-01-20 19:00

developer   ~0056041

Last edited: 2020-01-20 21:41

View 4 revisions

I have made it per my later EDIT of my note 0015926:0056032

So let's test in 2222

Test notes:
I have made the two sub-views mutually exclusive, so if "List (Folders)" is checked then "Grid (Folders)" is automatically unchecked.
BTW: This way the "Playlists (Grid)" and "Playlists (List)" are mutually exclusive, but "Playlist tree" still can be enabled together with either of them -- so it resolves my original objection in note 0015926:0054554 (to be able to hide media tree, show playlist tree and playlist grid at the same time -- like this ).

I am just not sure about the wording i.e. whether use "List (Folders)" or rather "Folders (List)". For the playlist I used it the other way, i.e. "Playlists (Grid)", but this can be adjusted anytime later.


2020-01-21 02:04

administrator   ~0056072

OK--will review in the next build.


2020-01-27 01:17

administrator   ~0056245

Tested 2223 and there are still cases in which the settings for Home > Playlists don't match the settings for Home > Playlists > PlaylistName

e.g. for
- Playlist1
 - - Playlist 1-1
 - - Playlist 1-2
 - - Track 1
 - - Track 2
 - - Track 3

i) Home > Playlists [Grid] shows playlists as a grid. Navigate to
Playlist1 [Grid | Playlists (list)]
--> Playlists display in list view

ii) Home > Playlists [List] shows playlists as a list. Navigate to
Playlist 1 > Playlists [Grid | Playlists (grid)]
--> Playlists display in a grid

One might say that these examples aren't bugs because the views are displaying in the manner that they're configured to display, however, it _is_ a bug because it shouldn't be possible to inadvertently switch the manner in which playlists are display from the top level of the hierarchy to the next level in.

The solution is that changes to how folders are displayed made at the Home > Playlists level must apply to the Home > Playlists > Playlist name level and vice versa. Possible implementations are either:
A) The view switcher icon works as it does today i.e.
- It switches between Grid | List for Playlists at the Home > Playlists level
- It switches between tracklist views at the Home > Playlist > PlaylistName level
If the user switches the subview for PlaylistName (e.g. to Playlist (Grid)) then when the user navigates to the Playlist, the view should automatically be set to the same view as the subview.

OR a possibly simpler approach:

B) The view switcher icon always changes how _Playlists_ (or Folders) are displayed (at both the Home > Playlists and Home > Playlists > PlaylistName levels), and for the subview configuration to:
 - Not include Playlists (list) or Playlist (grid)
 - Include only Playlist tracks (list), Playlist tracks (list by album), or Playlist tracks (grid)
 I think that the second approach might be much easier to understand (and probably to implement)


2020-01-27 20:29

developer   ~0056268

Last edited: 2020-01-27 22:13

View 12 revisions

The current approach in 2223 is the most flexible that we ever had, because:

1) it allows me to use 'Grid' for the root Playlists node and see the thumbs and assigned images to the playlists/containers (when I have just a small number of root categories and playlists)
while using the 'Playlists (list)' for individual playlists like "Imported playlists" where I have a large amount of sub-playlists.

The same goes for Folders where I want to see the grid with several drives and servers with thumbnails like this
while using 'List (folders)' to listing many sub-folders in [Folders > C:\ > Music]

2) it allows me to configure whatever combination of grid/list, i.e. List/Grid (folders), List/List (folders), List (by Album)/Grid (folders), List (by Album)/List (folders), Grid (by Album)/Grid (folders), Grid (by Album)/List (folders)

3) it allows me to set up MM5 with MM4 like view (i.e. to disable Playlists/Folders subviews when I want to see just tracks and using media tree)

4) it allows me to hide media tree, show playlist tree and playlist grid at the same time -- like this

- with your approach A) => item 1) is not feasible
- with your approach B) => items 1&3 are not feasible

So from my point of view no change is required (with except to EDIT and EDIT2).

EDIT: For better consistency and clarity we might want just rename:
"List" --> "List (Tracks)"
"List (by Album)" --> List (Albums)
"Grid (by Album)" --> Grid (Albums)

EDIT2: Testing it again there is a remainder from previous builds causing that changing root Playlists/Folders node to 'Grid' causes that the 'Grid (by Album)' is automatically used for tracks in individual sub-folders. I guess this should be independent again.


2020-01-28 03:22

administrator   ~0056296

I think that we may be getting lost in the details, perhaps because I wasn't clear in what I was trying to say. I'm just trying to make a simple point: that the format of folders/playlists shouldn't change as the user navigates higher/lower in the hierarchy. So if the user changes the format for containers at the top level and then navigates deeper, the format shouldn't change (and vice versa).

In 2223 the format of folders changes as the user navigates up/down and it's difficult to understand why. See:

Another confusing thing that you'll see in the video is that it's possible to disable Playlists from appearing entirely. I would argue that they should automatically be hidden if the tree is enabled (rather than allowing for this possibility).


2020-01-28 10:14

developer   ~0056304

Last edited: 2020-01-28 10:26

View 5 revisions

Yes, there was kind of misunderstanding, because what you have observed in the video was influenced by the bug that I later added as EDIT2 in my last note.
This is a survival from previous implementation when there was only List (folder+tracks) and Grid (folders+tracks) and it was persistent for whole the branch.
This needs to be fixed for 2224.

Otherwise I don't think that 'Playlist (grid)' should be automatically hidden when the tree is enabled, see my example 4) in my last note , also e.g. Windows Explorer shows containers both in the tree and the view and user can choose where to open the containers.
Also ability to hide both Playlists (list) and Playlists (grid) is required to meet the MM4 like design, i.e. my example 3) in my last note


2020-01-28 11:45

developer   ~0056306

Last edited: 2020-01-28 11:49

View 2 revisions

Fixed in 2224.

So please give a try with 2224 - I believe that it finally meets all the needs, fixes the issues mentioned by you while keeping the flexibility (all items 1,2,3,4 from my note 0015926:0056268 are feasible) + modified the wording slightly for clarity


2020-02-07 18:09

administrator   ~0056569

Tested 2224, and although it's flexible, it's still confusing:

1) List or Grid makes perfect sense at the root level, but as soon as the view goes lower (where there's a mix of Containers and Tracks), the view names are confusing. e.g.

a) Container containing only containers:
i List (Tracks)
ii List (Albums)
iii Grid (Tracks)
All three cases are confusing because switching views doesn't necessarily have an impact, and the View names don't make that clear.

b) Container containing only tracks:
i List (Tracks). OK, though '(Tracks)' is superfluous.
ii List (Albums). OK, though '(by Album)' would make more sense for consistency with other views.
iii Grid (Tracks). OK, though as already discussed elsewhere, I think that this view is totally unnecessary and even confusing--why do we need to display tracks as a grid for Playlists and Folders and not for anything else?!

2) As described at 0015926:0056296, it's confusing when the manner in which Playlists are shown (Grid or Folder) switches when navigating between different levels of the Playlists view.

I don't know why we didn't think of this sooner, but we already have a solution for how to display multiple levels of items within a view--just look at Music > Genres > GenreName [Browser]. It provides a simple means of switching the view at a high level, while also allowing to independently switch the manner in which tracks are displayed.

Applying this to playlists could look like this:

Playlists views: Grid, List (it would apply to containers i.e. no change)

Playlist>PlaylistNameX [Grid] could show:

[Playlist1] [Playlist2] [Playlist3] [Playlist4]

[Playlist5] [Playlist6]

[PlaylistNameX] [edit] [Play] [shuffle] [overflow] . . . . . . . . . . . . . . . List, [[List (by Album)]]v
# . Title . . . . . Artist . . . . . Album . . . . . Date . . . Genre . . . . . Rating . . .


Playlist>PlaylistNameX [List] could show:

[icon] Playlist1
[icon] Playlist2
[icon] Playlist3
[icon] Playlist4
[icon] Playlist5
[icon] Playlist6

[PlaylistNameX] [edit] [Play] [shuffle] [overflow] . . . . . . . . . . . . . . . [[List]], List (by Album)v
# . Title . . . . . Artist . . . . . Album . . . . . Date . . . Genre . . . . . Rating . . .

This approach eliminates confusion, is simpler/more usable, and doesn't compromise on flexibility.


2020-02-07 22:44

developer   ~0056580

Last edited: 2020-02-07 22:59

View 6 revisions

We can eliminate "Grid (tracks)" view. I believe that it has been added only because we wanted to have just "Grid" for both tracks and containers like in Windows Explorer (and Grid by album does not make sense for playlists)

As for the confusion, I guess that your latest approach does not solve much, because mostly playlists have no containers (just tracks). And in that case (and/or with the 'Info panel' and 'playlists' subviews disabled) the result would be

Playlists > PlaylistNameX [Grid]
# . Title . . . . . Artist . . . . . Album . . . . . Date . . . Genre . . . . . Rating . . .

... which is confusing ("Grid" view is showing just list of tracks !?)

Alternativelly we could rather add the "in view" grid/list switch for containers. But I don't think that it improves anything and just consumes one more row of screen space? In addition it would complicate the "Manage views" functionality.

So (for 5.0) I would suggest just eliminate the "Grid (tracks)" view and probably revert the wording to the default (i.e. unify it again with the others views for consistency)?


2020-02-11 11:04

administrator   ~0056604

Generally speaking, I'd agree with Ludek's proposal for 5.0 solution.

And, I'd also consider what I suggested some time ago, since I think that it not only is nicer, but would make thinks somewhat easier to understand:

8. Just a small aesthetic tweak - I'd introduce a subtle separator between the containers and tracks part. It probably could be just some 10-20px of empty space, even though a horizontal line with a low opacity in the main skin color could work too.


2020-02-11 21:58

administrator   ~0056609

As an example of the challenges with the current approach, try going through the exercise of configuring MM:
a) to use Tree view [there's no really good way without duplication of content)
b) to switch from Folders to Grid or vice versa for containers (thinking like a user who'll have a tough time disambiguating what View and Subview applies to tracks vs containers)

Ludek, re. your point that [Grid] wouldn't be the best name for a view that might only show playlist _tracks_ (and not containers). That's true, but the same holds true for [List] view that showed only Containers in a grid. That's why I was suggesting use of a 'Browser' type view (one that separates container and track presentation modes, and eliminates the need for different layers of views/subviews, and for most users to have to 'manage views..'/subviews to choose how containers are displayed. We could change the naming and use the folllowing pre-configured Views: enabled Subviews
[Brower]: Column filter, [Info panel], Folder tree, Folder list, [Folder grid], [Tracklist], [Status bar]
[List]: Column filter, [Info panel], Folder tree, [Folder list], Folder grid, [Tracklist], [Status bar]
[Tree]: Column filter, [Info panel], [Folder tree], Folder list, Folder grid, [Tracklist], [Status bar]
It seems almost ideal.

But we need to get this finished asap, and if the approach I'm advocating adds too much time/risk then let's just move forward as you've suggested. As to unifying the view wording, is this what you meant? :
Root Level
[List]: Folder tree
[Grid]: Folder tree

Container Level
[List]: Column filter, [Info panel], Folder tree, Folder list, [Folder grid], [Status bar]
[List (by album)]: Column filter, [Info panel], Folder tree, Folder list, [Folder grid], [Status bar]


2020-02-12 12:58

developer   ~0056613

Last edited: 2020-02-12 13:15

View 7 revisions

a) to use Tree view [there's no really good way without duplication of content)
=> If you mean duplication of containers in the tree and in the view then it is how Windows Explorer (and many apps) works too. So it is nothing unexpected.
And in MM5 user can disable the containers in the grid (having them only in the tree). So I don't see any limitation.

b) to switch from Folders to Grid or vice versa for containers (thinking like a user who'll have a tough time disambiguating what View and Subview applies to tracks vs containers)
=> This was clear once we had only 'List' and 'Grid' for both containers+tracks, but you didn't like grid for tracks so we are abandoning it and thus making it more complicated (but also more flexible).

Re: 'Folder tree' - I don't think that this sub-iew is needed for 5.0? It just duplicates the media tree.

Re: 'Browser' view: Yes, I agree that this could be a better name for the Grid/List mix of containers and tracks.

---- Sooo, with the above in mind I think that this chould work for 5.0 and is just a tiny/cosmetic change:

- for folders:
[Brower]: Column filter, List (Folders), [Grid (Folders)]
[List]: Column filter, [List (Folders)], Grid (Folders)
[List (by Album)]: Column filter, [List (Folders)], Grid (Folders)
[Grid (by Album)]: Column filter, List (Folders), [Grid (Folders)]

- for playlists:
[Browser]: Column filter, [Info panel], Playlists tree, List (Playlists), [Grid (Playlists)], [Status bar]
[List]: Column filter, [Info panel], Playlists tree, [List (Playlists)], Grid (Playlists), [Status bar]
[List (by Album)]: Column filter, [Info panel], Playlists tree, [List (Playlists)], Grid (Playlists), [Status bar]

Note1: the rationale for using " Grid (Playlists)" instead of "Playlist grid" is the original issue 0015712 where user expected that "Playlist grid" will show tracks in grid grouped by album ("Grid (by Album)") and was confused:
That said we should also consider adding "Grid (by Album)" to playlists (as it can be useful for auto-playlists, see the user's use-case on the forum) and was available in MM4 too.

Note2: The question is whether [Browser] should be the default view? i.e. do we want the containers to be shown as a list or as a grid by default?


2020-02-13 02:49

administrator   ~0056641

Regarding Note2: I'm suggest 'Browser' should probably be the default view.

As to other changes/discussions:
3) Re. Playlists Tree:
a) Terminology: For consistency of Playlists tree vs List (Playlists) vs Grid (Playlists), we should probably also use 'Tree (Playlists)'
b) The current configuration is unfriendly because:
. i) It duplicates the content in the main panel at the root level.
. ii) Users have to enable it at both the root and container levels.
Suggested solutions were to:
- Remove the functionality (I'd rather keep it for now and collect feedback)
- Disable the tree option at the root node (would be strange from a UI perspective to not have the tree at the root node)
- Rationalize the Root and Container nodes with a single set of settings (too risky/time consuming at this point)
So we'll leave it as is for now--available for those who want to try, but not enabled in any of the default views.

4) Re. Folders/Locations views:
a) As discussed above/offline: 'Tree (Folders)' subview could be useful here.
b) Is there a reason why [Status bar] shouldn't be available (at least for Locations views where this info is already in the DB)?


2020-02-13 14:07

developer   ~0056645

Last edited: 2020-02-13 18:58

View 4 revisions

8. OK, implemented the horizontal line separator in 2228

Note2: OK, implemented in 2228

3a) ok, makes sense, changed the terminology to "Tree (Playlists)"
3b) ok, makes sense

Note1: You haven't written what do you think about adding "Grid (by Album)" view to playlists, but because some users are seeking for it (and it was in MM4 too) then there is probably no downside adding it.
So I added it in 2228 together with the "Browser" view that is the default.

4a) Added in 2228
4b) OK, added 'Status bar' as sub-view also for location/folders (in 2228).


2020-02-13 17:18

administrator   ~0056647

5) fyi, you may have noticed this as you fixed things, but in 2227, the tooltip for the 'Grid' icon in the Folders/Locations nodes is 'Release date'


2020-02-13 20:27

developer   ~0056649

Last edited: 2020-02-13 21:14

View 2 revisions

5) Fixed in 2228 too
6) I have also noticed some 'Status bar' issues, tracking them separatelly as 0016360


2020-02-18 17:34

administrator   ~0056718

Verified everything in 2228 with the exception of 3b) which we're pushing, and one minor item:
Playlists > PlaylistName still includes Grid (by album) in contrast to what was last discussed at 0015926:0056613. Is this intentional?


2020-02-18 22:36

developer   ~0056720

Last edited: 2020-02-18 22:47

View 2 revisions

Yes, it was intentional. You have probably overlooked my Note1 above and the rationale for adding Grid by album for (auto-)playlists at