MediaMonkey forum

Please make Track Properties us the full playlist names - using just the childname as currently leaves me completely stuck when I have lots of playlists of same childname in different parents.

Thanks.

The "child name" is the full Playlist name though. What it seems you're looking for is showing the path, not full name. How do you propose this be done? "Test Main Playlist/Test Child Playlist"? What about playlists with "/" in the title? Perhaps a tree? That could involve listing playlists to form the tree that the file actually isn't in.

Yeah this is a tough one. The information of what parent node(s) the playlists is certainly helpful, especially for those with many playlists). A 2 column layout could be used one for parent node(s) and for playlist name.

Lowlander wrote:Yeah this is a tough one. The information of what parent node(s) the playlists is certainly helpful, especially for those with many playlists). A 2 column layout could be used one for parent node(s) and for playlist name.

Then there's a problem with a child of child of playlist (2 levels in).

I know, maybe a different visual separator can be used. In this case it doesn't need to be a character to separate the playlist nodes.

> maybe a different visual separator can be used

One that's already excluded from the name value, please e.g. a greyed bullet.

Each playlist (including child playlists) could be on their own line, but have the children indented, children of children indented twice, and so forth.

It still presents the issue of having to show playlists in the box that the track may not belong to, which are excluded presently.

My reply to this has mysteriously disappeared. As has one other message to the board recently. If a moderator has deleted them, I would appreciate him PMing me to confirm. Otherwise I shall repost the messages.

chrisjj,

I've just checked the moderator logs and I do not see any posts of yours that have been deleted. I see that Lowlander edited a few of your posts to add in a poll, but no deletions.

> I've just checked the moderator logs and I do not see any posts of yours that have been deleted.

Thanks NH - will repost.

Zeke129 wrote:Each playlist (including child playlists) could be on their own line, but have the children indented, children of children indented twice, and so forth.

Mizery_Made wrote:It still presents the issue of having to show playlists in the box that the track may not belong to, which are excluded presently.

Well it could either highlight the playlist nodes the tracks is on or only assume the last shown playlist would be the one the tracks in which does leads to duplicate entries like so: If song is on playlist 2 and 3

I don't like the new line for each node idea though, because one would need to scroll a lot if tracks are on many playlists and one heavily uses subnodes. On the other hand it would probably be the easiest to use.

> The "child name" is the full Playlist name though.

Well, I'd say not since it doesn't fully ID the list.

> What it seems you're looking for is showing the path, not full name. How do you propose this be done?

The same as it is done in the tree.

> That could involve listing playlists to form the tree that the file actually isn't in.

You've lost me there, Miz. Please explain.

Presently, only playlists that a track belongs to is lists in this window. There isn't a list of all the playlists there, with a simply check to indicate if it's on the playlist or not (the check there is used to remove it from playlists) Thus, if a Tree method was used to indicated which playlist belongs to which parent node, you could end up with playlists in this area that the track does not belong to. Nesting playlists currently doesn't "further filter" the parent node automatically. So I could set up a 'Dummy Playlist' with no tracks added or no auto-playlist criteria simply to use it as a "folder" if you will, for other playlists. So, if a tree is used to display the path to the playlist it's actually on, that top playlist that it doesn't belong to would need to be used.
See, if a tree is used to indicate this, then the purpose of this area would change from showing playlists it's in, to also needing to show playlists it isn't in. If this is done, might as well just duplicate the entire Playlist tree node in the Properties. Also, I believe if it appears several times in a manual playlist, then it's listed more than once in the Properties, so you would be duplicating this tree, because you couldn't simply add a second "Another Child Playlist" to the tree structure already present because that could indicate you have more than one playlist with the same name under that tree structure. Couldn't really use a parenthesis (adding how many times it's in the playlist in parenthesis or something) because then you would lose the ability to uncheck only one instance of that playlist.

And the name of a playlist is the name of a playlist. If I name a playlist "This is the Name", that's the name, if I dump it in a "This is not part of the Name" playlist, that doesn't change the fact that the first playlists' name is "This is the Name".

> | Parent Playlist <-- Doesn't belong to this, but it would need to be listed
> | \_ Child Playlist <-- Belongs to this, so it would be listed
> | \_ Another Child Playlist <-- Belongs to this, so it would be listed

The only problem I see there Miz comes from your particular interpretation of "belong to". I see no problem for the program.

What I would like is instead of each entry showing just the base name e.g. Another Child Playlist as currently , it shows a the full name... as a tree, or one line with reserved character separating the segments.

> And the name of a playlist is the name of a playlist.

And the full name of the playlist is the full name of the playlist.