View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0016391 | MMW 5 | Track Browser | public | 2020-02-24 15:11 | 2021-02-22 18:37 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 5.0 | ||||
| Target Version | 5.0 | Fixed in Version | 5.0 | ||
| Summary | 0016391: List views are not configured/saved per-node | ||||
| Description | I 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 Reproduce | 1 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 Information | http://www.mediamonkey.com/forum/viewtopic.php?p=465530 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2238 | ||||
| related to | 0015724 | closed | Ludek | Addon for per node sort columns persistence like in MM4 (not per collection like in MM5) |
| related to | 0014659 | closed | michal | Column headings for List View does not persist sometimes for collection |
| related to | 0016322 | closed | petr | View configuration: Sort config doesn't match sort order |
| related to | 0016430 | closed | petr | Custom Views: Use In issue |
| related to | 0015584 | closed | petr | Views: Subviews should persist on a per-view basis |
| parent of | 0016382 | closed | rusty | Track Browser: Views do not look like that have same default Sort |
| related to | 0015756 | resolved | rusty | 'Manage views' functionality seems broken / incomplete |
| related to | 0016405 | closed | michal | Grid View: Image size customization |
| related to | 0016437 | closed | petr | Views: refreshing reverts sorting / columns / column order in several cases |
| related to | 0016479 | closed | michal | Set image size: should not apply to navigation nodes |
| related to | 0017141 | resolved | Ludek | Column Filter doesn't persist when switching Views |
| related to | 0017594 | feedback | Ludek | Ability to copy configured nodes between various views |
|
|
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 |
|
|
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---------------------------> |
|
|
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. |
|
|
Implemented except iii ... assigning to Ludek for iv |
|
|
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 |
|
|
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? |
|
|
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' !! |
|
|
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... |
|
|
Removed in 2232. |
|
|
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. |
|
|
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...' |
|
|
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 |
|
|
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. |
|
|
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. |
|
|
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! |
|
|
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 ? |
|
|
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) |
|
|
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 ? |
|
|
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. |
|
|
Fixed |
|
|
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 |
|
|
Fixed |
|
|
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. |
|
|
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 |
|
|
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. |
|
|
Fixed |
|
|
Verified 2238 (1v) isn't fixed--it's something we can consider for the future. |
