View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000021 | MMW v4 | Main Panel/Toolbars/Menus | public | 2003-01-30 01:25 | 2006-03-06 20:27 |
| Reporter | rusty | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Summary | 0000021: Tree: empty nodes should not have a '+' | ||||
| Description | When the tree is refreshed, all nodes have '+' so that they can be expanded, even nodes without children. This is an annoyance. | ||||
| Additional Information | Assigning this priority of 'high' because even though the practical impact is not that great, the impression it gives is of an unpolished package. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
|
|
It is because it isn't known at the time these nodes are drawn if they have any descendants (it would require another query to the database - would be slower). In some specific cases it could be probably solved without any significant slowdown. Is there any particular node you had in mind? |
|
|
It's a consistency thing i.e. a user expects that _all_ cases in which a node has no hierarchy that it doesn't have a +. Implementing for some nodes and not for others won't fully resolve the problem, although it could lessen it if we first fix the nodes/subnodes that are most commonly used (e.g. all nodes sub to Library). p.s. how much slower would it actually be? edited on: 02-05 13:06 |
|
|
I can try to implement it and we will see. Another option is not to have such nodes which sometimes have and sometimes don't have children. When we add node "Unknown" as a child for all applicable nodes, the + mark can be always visible (an example - all artists would have "Unknown" subnode if they have songs without album assignment). |
|
|
I like the idea of having 'Unknown' for cases where the album is unknown, although I'm not totally clear on how this solves the + problem. p.s. I went through the entire node tree, and noted this issue in the following nodes: +Cached +Queued for Caching +Previews +Duplicate song content I'm not sure why only these nodes have a '+', as there are others that also don't have children, but don't have a '+'. |
|
|
My proposal regarded artist and album nodes. The nodes you mentioned need '+', because: Cached, Queded, Previews: when expanded show a list of artists (if there are any) Duplicates: When there are duplicates, they are represented as nodes (MD5 signatures are needed) |
|
|
ok |
|
|
Assigned to r to define all problem nodes in latest builds. |
|
|
I went through the entire tree and found the following nodes are _always_ initially preceded by a '+', even if the node in question does not contain any subnodes. (In reference to your earlier comment, I'm not arguing that these should never have a '+', only that they should only have a '+' when they contain subnodes). /Library/Artists/Artist -- even if it doesn't contain any albums /Library/Files to Edit/Duplicate Content -- even if there's no subnodes /Virtual CD/Virtual CD Queue -- even if there are no subnodes (Artists) /Previews -- even if there are no subnodes (Artists) /Playlists/AutoPlaylists -- even if there are no child playlists /My Computer/C:/Folder/ -- even if it doesn't contain subfolders /My Computer/D:/ even if it contains no subfolders |
|
|
This seems to be either fixed, or nodes must have '+' so that user can only try to expand them when needed. |
