View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0021101 | MMW 5 | Main Panel: Toolbars & Menus | public | 2024-07-23 18:37 | 2025-02-06 23:06 |
| Reporter | zvezdan | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | assigned | Resolution | open | ||
| Product Version | 5.0 | ||||
| Target Version | 2024.2 | ||||
| Summary | 0021101: Send to > Playilst should display auto-playlists (that have static playlist as children) | ||||
| Description | Users could create auto-playlists that contain static playlists as children. Users would want to use the Send to > Playlist option to add files to such static playlists. But they cannot do that because MM doesn't display auto-playlists in that menu at all. It is not impossible to implement. My Export/Import Playlists add-on for MM<=4 has a very similar option in the menu displaying such auto-playlist (and its children). It is displaying even auto-playlists that have static playlists as grand-children, i.e. recursively, on any nested level. Of course, the Import option of my add-on is disabled for auto-playlists, but not for its static children. And my add-on doesn't display an auto-playlist in the menu only if it doesn't have any static playlist as a (grand-)child on any level. Actually, maybe you should display all auto-playlists in the Send to > Playlist menu, even those that don't have any static playlist as a child. Because an user could want to click on the Add playlist icon on the right side of menu item representing an auto-playlist to add a static playlist as a child to it. | ||||
| Additional Information | https://www.mediamonkey.com/forum/viewtopic.php?t=106402 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
|
|
The root cause of this issue is described at 0000204 (the fact that MM doesn't differentiate between playlists and containers and/or the fact that contained items don't actually have any 'containment' relationship between a parent and child playlist) and that a solution as described above would cause more confusion when users try to send tracks to an autoplaylist. It's certainly doable, but not advisable at this stage of the release process. |
|
|
I am not sure if I understand what are you saying. Maybe containers are not visually differentiated from playlists in GUI, but the Playilsts table in the database has their relationships strictly defined. Actually, containers (parent playlists having children) _are_ visually distinguished having the right arrow icon on the right side of their items in the Send menu and the expand/collapse icon in the tree panel. Besides, every playlist could be made as a parent (container), even autoplaylists. So, in my opinion, there is no any point of making them additionally differentiated in GUI. There wouldn't be any confusion in users if you implement the solution that I have implemented in my add-on (with Send menu displaying only autoplaylists having static playlists as children), because in such case users cannot click on the autoplaylist items, but only on their right-side arrow icons to open their submenus. However, even if you decide to display all autoplaylists in the Send menu (including those autoplaylists that don't contain any static playlist as a child): solution 1: autoplaylist item in the menu could be displayed, but disabled (only the add icon on the right side of the item could be enabled); or solution 2: autoplaylist item could be enabled, but the program could display a message box saying that it is not possible to send files to the autoplaylist if user clicks such menu item. But, the second solution is not advisable because it would require adding strings for all supported languages. |
