View Issue Details

IDProjectCategoryView StatusLast Update
0016391MediaMonkey 5Track Browserpublic2020-04-01 15:30
Reporterrusty 
PriorityimmediateSeveritymajorReproducibilityalways
Status closedResolutionreopened 
Product Version5.0 
Target Version5.0Fixed in Version5.0 
Summary0016391: List views are not configured/saved per-node
DescriptionI believe that this is a relatively recent regression, but in build 2228, all list views are identical!
e.g. Music > Composers view should have the composers column enabled and sorted by composer
Music > Publishers view should have the publishers column enabeld and sorted by publisher

Now when the user switches from one node to another the List view is always identical!

This issue needs to be fixed, and the default columns/sorts need to be re-enabled.
Steps To Reproduce1 Enable List view for 'All tracks', 'Albums', and 'Artists' nodes
2 Switch to 'Albums' node and enable 'Album Artists' column
--> 'Album Artists' is enabled in 'All tracks' node (it shouldn't have changed)!
3 In 'All tracks' node sort by Rating
--> In 'Albums' node tracks are now sorted by rating (they should be sorted e.g. by albums as they were)
Additional Informationhttp://www.mediamonkey.com/forum/viewtopic.php?p=465530
TagsNo tags attached.
Fixed in build2238

Relationships

related to 0015724 closedLudek Addon for per node sort columns persistence like in MM4 (not per collection like in MM5) 
related to 0014659 closedmichal Column headings for List View does not persist sometimes for collection 
related to 0016322 closedpetr View configuration: Sort config doesn't match sort order 
related to 0016430 resolvedpetr Custom Views: Use In issue 
related to 0015584 closedpetr Views: Subviews should persist on a per-view basis 
parent of 0016382 resolvedrusty Track Browser: Views do not look like that have same default Sort 
related to 0015756 resolvedrusty 'Manage views' functionality seems broken / incomplete 
related to 0016405 closedmichal Grid View: Image size customization 
related to 0016437 resolvedpetr Views: refreshing reverts sorting / columns / column order in several cases 
related to 0016479 newpetr Set image size: should not apply to navigation nodes 

Activities

rusty

2020-02-27 19:47

administrator   ~0056931

Based on my discussion with Ludek, the current implementation actually is along the lines of B) i.e.
- Collections define: Criteria, Nodes
- Nodes define: Which Views are used from a per-Collection list of default Views and a Global list of custom Views
- Views define: Presentation, Columns, Sorts, View Elements

Going back to the MM4 approach in which Collections define: Criteria, Nodes, Columns/Column order and Column Sort order is problematic for a number of reasons:
- afaik, it's more work (since the current implementation is closer to B)
- It would make it impossible to define columns different for different Views (e.g. List vs Simple List vs List(by Album) -- currently they are indepeendently configurable (per View which by default is consistent across the Collection)
- It splits different pieces of View configuration arbitrarily
- It returns the limitation of sorting on key columns that are not displayable (without compromising other views) unless we create hacks for the Composers node / Publishers node / etc.

Since the current implementation is relatively coherent except for a few bugs, we should just fix those bugs. i.e.
i) Allow users to create Custom views if desired (e.g. for Composers node). And if we wanted, in the future, we could pre-define custom nodes. This is already implemented (though there are some bugs).

ib) iiuc, Custom views are currently defined globally. We might want them to be per-Collection instead like regular views for consistency.

ii) To eliminate duplicate/conflicting functionality, 'Choose Columns...' should link directly to the 'Manage Views...' dialog for the currently active View.

iii) We'd have to rename views so that they have unique names per-Collection unless they are shared across nodes within the Collection e.g.:
Playing: List --> List (Playing)
Music : List -- no change needed since it is the same view as is used in Music > All Tracks [List] and in Music >
etc... (I'll review other similar changes once we agree that this is the right approach)

iv) Adjust sorting configuration since it shouldn't be View-specific:
 - In Manage views, 'Sorting' should be changed to 'Default Sort:' and we may want to add the 'Reset sort' button to this dialog
 - sort order should persist independently per node-[View] so that e.g. if the user sorts by Composer in Classical > Composer [List] that it doesn't change when the user changes the sort order in Music [List].

v) Adjust image configuration since it isn't View-specific
 - 'Image size...' should not appear in 'Configure View..' for views that don't contain configurable image sizes (e.g. List)
 - Image size config dialog should indicate what types of views the image size is being configured for. e.g. Header:
 . . Image size: all Grid views
 . . Image size: all Browser views
 . . Image size: all List (by Album) views

rusty

2020-02-27 23:11

administrator   ~0056932

Last edited: 2020-02-28 20:54

View 3 revisions

fyi, I discussed this with Petr and he also confirmed that B) is most similar to the current implementation. He agrees with the suggested approach with the following modifications:
ib) Custom Views could be applied to any number of Collections. e.g. in 'Configure View'
Name:
Type:
Use in: _CollectionName1, CollectionName2,_v_ (this is a combobox that allows the user to select 1 or more Collections)

iii) Rather than renaming all Views to better communicate where they're used, it would be preferable to keep the current relatively simple/descriptive names and indicate what Collection/Nodes they're used in. e.g. in 'Configure View'
Name:
Type:
Use in: <Collection Name>: <NodeName1>, <NodeName2>, <NodeName3>, .... (note: this is a non-editable list)

v) The image size config dialog should only appear in Browser and Grid View settings, and use a common setting for both (images in [List (by album)] Views are configured by resizing the column width).

To avoid confusion about which views it's applied to, the dialog should indicate:

Image size
-----------------
Use for: _Browser, Grid_
              %xxx
<-----------o--------------------------->

jiri

2020-03-02 10:50

administrator   ~0056989

Generally speaking sounds good, just:

ib) If we want to limit the content where views are available (which sounds good, even though possibly not critical), I'd rather define for which content is a View supposed to be used. Each Custom View would have:

Media Types: _Music, Audiobooks, ..._  {select zero, one or more}

And such a view would be available in Collections with the selected content. Note that his approach is also more friendly to Playlists (allows Custom Views usage there).


iii) Not sure whether this is really needed, I'd rather defer and decide later.

petr

2020-03-04 16:06

developer   ~0057044

Last edited: 2020-03-05 17:27

View 2 revisions

Implemented except iii ... assigning to Ludek for iv

Ludek

2020-03-05 17:50

developer   ~0057056

Last edited: 2020-03-05 17:57

View 7 revisions

Re: iv) I wonder whether any change is needed at all? As it already works like requested (because sort orders and column visibility are saved per collection).
This is already true: if the user sorts by Composer in Classical > Composer [List] that it doesn't change when the user changes the sort order in Music [List].
i.e. sort orders and columns in 'Classical > Composer [List]' are already independent from 'Music [List]'

So resolving for now to test in 2230 and review whether any furher changes are really needed for 5.0

Ludek

2020-03-05 23:20

developer   ~0057065

Last edited: 2020-03-06 12:26

View 5 revisions

iv) Yes, I agree that it's complicated to understand having columns and default sorts configured independently, therefore I suggested to leave it as is, i.e. have both configured per collection/view.

i.e. 'Music > Albums [List]' shares the columns sort&visibility with 'Music > Genres [List]', but is independent from 'Music > Publishers [CustomList]' and independenr from 'Classical > Album [List]'

BTW: I guess that if someone wants to use 'Music > Publishers [List]' (instead of default 'Music > Publishers [Grid]') then he would also want to use 'Column FIlter' view element with Publisher as the first column of the 'Column Filter' which leads to the 'CustomList' anyway.

iii) maybe we could add just explanatory text (to the Configure View dialog) that the configured values for the default views are stored per collection?

Ludek

2020-03-12 10:39

developer   ~0057171

Last edited: 2020-03-12 10:40

View 3 revisions

As for the difficulty to understand what is being configured when 'Managing Views'. i.e. elements persist per node while columns/sorting persist per collection.

I guess we could resolve it either:

A) by changing the headings. e.g.
'Sorting:' --> 'Sorting (per collection):'
'Columns:' --> 'Columns (per collection):'
'Elements:' --> 'Elements (per node):'

B) remove Elements from 'Configure View' dialog entirely

I guess B) could be preferred now as now (by testing it) it does not work as one would expect anyway.
i.e. disabling 'Column Filter' element in 'CustomList' disables the 'Column filter' also for 'List' !!

jiri

2020-03-12 11:25

administrator   ~0057173

I agree, I'd remove Elements.

I even wonder, whether we should ever return them. It seems to me that their configuration here isn't necessary and could be left in the View configuration pop-up only. To be decided later though...

petr

2020-03-12 12:46

developer   ~0057174

Removed in 2232.

rusty

2020-03-12 19:38

administrator   ~0057182

Last edited: 2020-03-13 09:28

View 6 revisions

It seems that there was some confusion about this issue due to a bug (which is why I'm reopening this): Column/Sort settings were (in 2231) being saved per Collection+View Type rather than per Collection+View e.g. for Custom View: Test (View Type:List), modified Column/Sort settings are applied to View:List: https://www.screencast.com/t/oga5Zft1xhTs

Once this is fixed:
- Columns/Sorts will persist per combination of Root Node (where root node=Collection or Playing or Playlist or Location) + View (including Custom Views)
- View elements: are persisted per combination of Node (e.g. Artists, Albums, Ratings...) + View.

Post 5.0 we'll improve 'View management' so that it contains more than just Column/Sort settings, if possible.

Ludek

2020-03-13 09:09

developer   ~0057184

Last edited: 2020-03-13 11:45

View 3 revisions

Fixed in 2232

Note that Petr removed the 'Use in: Everywhere' choice, because it was particuary problematic when:
- using 'Browser' views (e.g. podcast browser view with episode list is incompatible with other collections) and various 'Browser' views are incompatible one with the other
- 'List' view in playlist where 'List' in playlist is incompatible with 'List' in Music (it has the '#' column - playlist order column)
- 'Tabbed view' is only available in Podcasts
i.e. there is currently no general way how to find where the particular view can be used
And if we would add this kind of information/restriction then it would just complicate the code and make it harder mainly for addons developers (that would be adding own views)

EDIT: I would also suggest to change wording 'Manage views...' -> 'Customize views...'

rusty

2020-03-19 15:36

administrator   ~0057228

Last edited: 2020-03-19 17:26

View 2 revisions

In 2232:
1a) There are various issues with persistence of Sorts/Columns/Column order (see 0016437), but they generally seem to persist per combination of Root Node (where root node=Collection or Playing or Playlist or Location) + View (including Custom Views). I'll test this more completely after 0016437 is resolved.

2) Re. persistence of View Elements, at 0016391:0057182, we'd decided that it would be based on a combination of Node + View. As discussed:
"if the user enables Column Browser for:
1) Music [List] , it wouldn't be enabled for Music > Artists [List]
2) Music [List], it wouldn't be enabled for Music > All tracks [List]
3) Music > all tracks [list], it wouldn't be enabled for Music > All tracks > List(by album)"

But from what I see in limited testing of this in 2232, View Elements persist based on Root Node + View e.g.
1 Enable 'Column filter' in Music > All Tracks [List]
--> it's also enabled in Music > Artists [List], Music > Composers [List], etc. !
2 In the 'Column filter' for Music > Composers [List], change the second column of the 'Column filter' from 'Artist' to 'Composer'
--> in Music > Artists [List] the second column of the 'column filter' is now 'Composer'!

Can you clarify how this is supposed to be working now (i.e. was there a change from our last discussion)?

NOTE: based on the approach that we seem to be taking, List views in all nodes are exact duplicates of the List for All Tracks. When we'd originally specced the inclusion of List views for different nodes, it was based on the assumption that e.g. Composer node might include additional columns (e.g. 'Composer'--though we've since rejected that idea as too confusing) and/or a Column Browser with the 'Composer' column. But if all of the list views are identical, is there any reason for them?

3) View In: has been removed completely (i.e. it's not just the Use in: Everywhere option that was removed). So now MM5 again has multiple identically named Views that make it unclear what they're applied to.
[Edit]: tracked at 0016430

rusty

2020-03-19 16:02

administrator   ~0057229

2b) Re. persistence of View Elements, they also seem to persist based on View Type! e.g.
1 For Classical Music > all tracks [List], enable Column Browser
2 Switch to Classical Music > all tracks [Test] (which is View Type:List) and disable the Column Browser
3 Switch to Classical Music > all tracks [List]
--> Column Browser is gone!
Is this intentional?

Note: Persistence of View Elements doesn't occur across different View Types (i.e. the Column Browser displays/or not in [List(by album)], [Grid (by album)] views independently of what is configured in the [List] & [CustomList] views.

rusty

2020-03-19 17:24

administrator   ~0057231

4) Re. persistence of Sorts, we may want to re-think how 'Reset Sort Order' works. Currently it resets to a pre-defined sort order that may have nothing to do with what the user considers to be the desired default sort order. For example:
1 In Manage Views, user sets his desired Default Sort order
2 In Music > Ratings [List] the user sorts by rating
3 User switches to Music > All tracks and uses 'Reset sort order' to get the desired sort
--> MM switches to the hardcoded default sort (rather than the sort that was configured by the user)!

The problem is even worse for some other Collections (where the default Sort isn't as well thought out)

In other to fix this, the 'Manage Views' screen would have to be treated as Managing the Defaults. So e.g. Sorting --changes to --> Default Sort. And when the user changes the sort order within a View, it doesn't change the default sort.

This is probably not critical, but noting it in case you thing it's also preferable from a technical perspective.

petr

2020-03-19 17:46

developer   ~0057233

Last edited: 2020-03-19 17:47

View 2 revisions

re 2b) yes it is intentional as elements are no longer handled by custom view, but by type. When [Test] custom view is View Type: List ... then Column browser is disabled for type List.
re 4) in Manage Views you're always get\set CURRENT sort order for a view type (or custom view) ... not default sort order!

Ludek

2020-03-19 18:46

developer   ~0057234

Last edited: 2020-03-19 19:17

View 6 revisions

2b) yes, persistence of View Elements based on View Type makes sense to me and MM5 has always worked this way. It is also more compatible with MM4 where 'Column Browser' is enabled for whole collection.
I am not aware of any decision to make it based on a combination of Node + View?

I think that generaly it works fine currently, i.e. that columns/sorts/elements are persistent based on combination of view type and collection.

3) Yes, "Use in" was removed because of the reasons described in my note 0016391:0057184.
i.e. I think that adding it back would just further complicate the things without making anything clearer.

4) I think that there is a general confusion about how this is supposed to work, we have two choices:
ch1) make something like default sort configured when custom view is created -- where making sort changes by clicking columns header in tracklist has no impact on the default sort
ch2) make just one sort -- when any change to sort order (be it by clicking columns header) is propagated and saved for the custom view

Petr indicated that ch1) was a bug and it should act as ch2) -- not sure what is desired here ?

Ludek

2020-03-19 19:55

developer   ~0057235

Last edited: 2020-03-19 20:02

View 6 revisions

2b/3) I think that the main confusion here is that 'Music > All Tracks [List]' shares the columns/sorts/elements with 'Music > Artists [List]' but does not share the columns/sorts/elements with 'Music > Artists > ABBA [List]'.
The reason is that ABBA can have also 'Info Panel' element while 'All tracks' can't and thus uses different view handler.

The most easiest solution would be to differentiate also 'Music > All Tracks [List]' from 'Music > Artists [List]' view handlers so that they don't share columns/sort/elements.
This would be particulary useful because of the clarity issues and the consistence.
Note that this way custom views created for 'Artist > ABBA [List]' is not available for 'All tracks' (as it is incompatible)

rusty

2020-03-20 02:29

administrator   ~0057239

Last edited: 2020-03-20 11:12

View 2 revisions

2b) can be understood as Ludek described at 0016391:0057235 and will be fixed as described by Ludek.

3) (the fact that the user has no way of differentiating between the three different Views that Ludek described can be fixed as described at 0016430.

4) The current implementation re. default sorts is ch1), however, this is problematic because it results in sorts that aren't necessarily visible in the default view. We could either:
- define new default sort orders that are better suited to the default views
- OR better yet, take the ch2) approach so that users can re-define the default sort orders

So to summarize, after this revision:
- Views define: View Type, Columns & Sorts, View Elements per Node (where node= Collection > Node, Collection > Node > Subnode , Now Playing, Playlists)
- View Type defines: Non-configurable elements of the View

5) With the above in mind, would it make sense to add View Elements back into the View Config ?

Ludek

2020-03-20 11:14

developer   ~0057244

Last edited: 2020-03-20 12:08

View 10 revisions

2) is fixed in 2234
i.e. all is saved per node: elements, columns order, columns visibility, columns widths (including columns of 'Column Filter') etc.

3) note that fix of 2 did not broke the current compatibility of custom views, i.e. CustomList created based on 'Music > All Tracks [List]' is also available in 'Music > Albums'.

4) I am not sure whether ch1 or ch2 is better, but currently it is still broken and does not work properly/conistently for custom views:
- go to 'Music > All tracks [List]' and click 'Date' column to sort by Date, go to Manage Views > List and Sorting is Date A..Z (as expected)
- go to 'Music > All tracks [CustomList]' that is sorted by Artist and click 'Date' column to sort by Date, go to Manage Views > CustomList and Sorting is Artist A..Z !!
So it looks to me that for default views the ch2) is implemented while for the custom views the ch1) is !?
I guess we should unify it to ch2) i.e. the sort changes by clicking the columns header should be properly propagated and saved.

5) Yes, I guess that we might want to add Elements back to the 'Configure View...' dialog.
But even if not then there is bug that needs to be fixed (again related to custom views only).
- go to 'Music > All tracks [List]' and enabled 'Column Filter' element
- switch to [Grid (by Album)] => 'Column Filter 'is not enabled (as expected per 0015584 )
- switch to [CustomList] => 'Column Filter' is enabled!! (unexpected)
- try to disabled 'Column Filter' for the [CustomList] => nothing happens !!

Assigned 4&5 to Petr for fix as the issues are related only to the custom views.

petr

2020-03-20 17:01

developer   ~0057248

Fixed

Ludek

2020-03-20 19:28

developer   ~0057251

Last edited: 2020-03-20 20:04

View 4 revisions

4) still isn't fixed for custom views:
- go to 'Music > All tracks [CustomList]' that is sorted by Artist and click 'Date' column to sort by Date, go to Manage Views > CustomList and Sorting is Artist A..Z !!

6) Another issue with CustomList:
- create CustomList and enable Column Filter => all is OK, press F5
=> Column Filter is empty! This issue does not appear for List

petr

2020-03-20 21:07

developer   ~0057258

Fixed

rusty

2020-03-30 17:42

administrator   ~0057413

1v) Image Size dialog tweak: the dialog currently has no header. I'd suggest a minor tweak so that the following appears in the header (instead of 'Use in:' in the dialog body):

Image size: <view1>, <view2>, ...
---------------------------------

This would be consistent with the approach used in the Manage Views dialogs (per 2b/3 above).


4) Issues with columns/sort settings not saved are reopened at 0016437


5a) Music [Browser] View Elements settings sometimes don't match the actual settings! e.g.
1 Navigate to Home > Music [Browser]
2 Click 'Manage views' > Browser
--> All View Elements are checked off
3 Navigate to Home > Music [Grid (by album)]
4 Click 'Manage views' > Browser
--> All View Elements are unchecked!

Similarly:
1 Navigate to Music [Grid (by album)]
2 Disable status bar
3 Navigate to Music > Albums [Grid (by album)]
--> Status bar is enabled
4 Navigate to Music > Albums [List]
5 Click 'Manage views' > [Grid (by album)]
--> Status bar Element is unchecked!


7)
a) Files to Edit > Duplicate Content [List] seems to show different column settings than for all other Files to Edit [List] views. Is that on purpose?
b) Files to Edit > Multiple Artist Albums and Files to Edit > Ungrouped Multiple Artist Albums both only have Grid Views (which aren't useful for editing purposes since they don't display the full text). They should also at least show 'List (by Album)' views.

petr

2020-03-31 08:51

developer   ~0057420

Last edited: 2020-03-31 13:57

View 3 revisions

1v) i think some note like 'this will apply to all grid/image views' should be enough ?
5) fixed
7a) yes it is ... this view is a bit different as we need to show what content is duplicated
7b) fixed

rusty

2020-03-31 15:10

administrator   ~0057424

1v) I was confused and thought forgot that the implementation was Global except for 'List (by Album)' views. To fix, I'd implement the following in the title bar (and get rid of the Use for: entry):

Image size (browser & grid views)
---------------------------------

1v)ii) In addition, the 'Image size...' button should not appear for View configurations that it doesn't apply to (e.g. List, List by Album, etc.)

1v)iii) In the future, we may want to distinguish between 2 types of images: Images for subnodes vs Images for content (e.g. currently the ratings, classification, and Files to Edit nodes have really large subnodes when in reality, must users would prefer/expect buttons similar to those at the top of Browser nodes.

petr

2020-03-31 17:16

developer   ~0057426

Fixed

rusty

2020-04-01 15:14

administrator   ~0057438

Verified 2238 (1v) isn't fixed--it's something we can consider for the future.