View Issue Details

IDProjectCategoryView StatusLast Update
0000021MMW v4Main Panel/Toolbars/Menuspublic2006-03-06 20:27
Reporterrusty Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Summary0000021: Tree: empty nodes should not have a '+'
DescriptionWhen the tree is refreshed, all nodes have '+' so that they can be expanded, even nodes without children. This is an annoyance.
Additional InformationAssigning this priority of 'high' because even though the practical impact is not that great, the impression it gives is of an unpolished package.
TagsNo tags attached.
Fixed in build

Activities

jiri

2003-02-05 13:31

administrator   ~0000046

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?

rusty

2003-02-05 18:06

administrator   ~0000051

Last edited: 2003-02-05 18:06

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

jiri

2003-02-06 09:03

administrator   ~0000060

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).

rusty

2003-02-06 16:17

administrator   ~0000067

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 '+'.

jiri

2003-03-27 07:53

administrator   ~0000667

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)

rusty

2003-03-27 13:26

administrator   ~0000669

ok

rusty

2003-05-29 15:44

administrator   ~0001301

Assigned to r to define all problem nodes in latest builds.

rusty

2003-06-02 18:22

administrator   ~0001375

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

jiri

2006-03-06 20:27

administrator   ~0006993

This seems to be either fixed, or nodes must have '+' so that user can only try to expand them when needed.