MM currently uses a plain flat grid to display the songs. Of course you can sort it on multiple columns and choose what columns are shown. That is fine and very 1990's-ish, but I think it would be nicer to take advantage of a new type of UI control that wraps a grid in a tree. So that the nodes of the tree "become" whatever you sorted the grid on. And you can expand the nodes to see only the sections of the grid you want at that time. Using such a control instead of the full non-hierarchical grid right now would also be better for performance in that you can open up only a segment of your current working set in view and leave other branches collapsed. Expanding a branch does a "just in time" read of the database (lazy loading). Here is an example of a Grid control that is wrapped by a Tree. A good default behavior for MM would be that the tree nodes are determined by the current sort order hierarchy of your autoplaylist or other data source, and it would open up collaped by default and the user can then open only the nodes they want. The contents of each node would be a grid with configurable columns just like today. Changing the sort order of any node would also automatically re-generate the tree branches. It would also prevent reading of 200,000 rows from the database when the user knows under what node his song will be. We use a control like this in a application at work and it makes working with large amounts of data in grids a much easier endeavor. Just a suggestion...
http://www.telerik.com/products/wpf/treelistview.aspx
Why just a big grid, why not a tree/grid?
Moderator: Gurus
-
windcrest77
- Posts: 399
- Joined: Sat Aug 07, 2010 12:28 pm
Re: Why just a big grid, why not a tree/grid?
There are several topics on this.
You do know that you have 2 "tree" objects already, one being the Media Tree and the other the Column Browser. Also in the Art views you have grouping and can collapse. Add to that the Search and Find More from Same I never find myself displaying 200,000 tracks unless I wanted to. I do appreciate the idea, but I think it would mean more work for me.
A similar idea where one would have a list of Artist in the Filelisting which can then be clicked to see the Albums which then can be clicked to see Tracks is something that I like more if properly implemented. IE the Artist would have the Artist comment shown (for Bio), the Album would have the Album comment shown. Also stackable Album Artwork is something that has been requested as well as the ability to click an Album in the Art view and be taken to the tracklisting of the Album instead of the same Album in Art view again and again.
You do know that you have 2 "tree" objects already, one being the Media Tree and the other the Column Browser. Also in the Art views you have grouping and can collapse. Add to that the Search and Find More from Same I never find myself displaying 200,000 tracks unless I wanted to. I do appreciate the idea, but I think it would mean more work for me.
A similar idea where one would have a list of Artist in the Filelisting which can then be clicked to see the Albums which then can be clicked to see Tracks is something that I like more if properly implemented. IE the Artist would have the Artist comment shown (for Bio), the Album would have the Album comment shown. Also stackable Album Artwork is something that has been requested as well as the ability to click an Album in the Art view and be taken to the tracklisting of the Album instead of the same Album in Art view again and again.
Download MediaMonkey ♪ License ♪ Knowledge Base ♪ MediaMonkey for Windows 2024 Help ♪ MediaMonkey for Android Help
Lowlander (MediaMonkey user since 2003)
Lowlander (MediaMonkey user since 2003)
Re: Why just a big grid, why not a tree/grid?
+1000windcrest77 wrote:MM currently uses a plain flat grid to display the songs. Of course you can sort it on multiple columns and choose what columns are shown. That is fine and very 1990's-ish, but I think it would be nicer to take advantage of a new type of UI control that wraps a grid in a tree. So that the nodes of the tree "become" whatever you sorted the grid on. And you can expand the nodes to see only the sections of the grid you want at that time. Using such a control instead of the full non-hierarchical grid right now would also be better for performance in that you can open up only a segment of your current working set in view and leave other branches collapsed. Expanding a branch does a "just in time" read of the database (lazy loading). Here is an example of a Grid control that is wrapped by a Tree. A good default behavior for MM would be that the tree nodes are determined by the current sort order hierarchy of your autoplaylist or other data source, and it would open up collaped by default and the user can then open only the nodes they want. The contents of each node would be a grid with configurable columns just like today. Changing the sort order of any node would also automatically re-generate the tree branches. It would also prevent reading of 200,000 rows from the database when the user knows under what node his song will be. We use a control like this in a application at work and it makes working with large amounts of data in grids a much easier endeavor. Just a suggestion...
http://www.telerik.com/products/wpf/treelistview.aspx
Seven Ultimate X64 SP1 / Sansa Clip 2go (with RockBox)
Re: Why just a big grid, why not a tree/grid?
Continue here: http://www.mediamonkey.com/forum/viewto ... =4&t=56720
Download MediaMonkey ♪ License ♪ Knowledge Base ♪ MediaMonkey for Windows 2024 Help ♪ MediaMonkey for Android Help
Lowlander (MediaMonkey user since 2003)
Lowlander (MediaMonkey user since 2003)