View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0014447 | MMW 5 | Playlists | public | 2017-10-06 13:47 | 2020-01-15 01:43 |
| Reporter | jiri | Assigned To | |||
| Priority | high | Severity | minor | Reproducibility | N/A |
| Status | closed | Resolution | fixed | ||
| Target Version | 5.0 | Fixed in Version | 5.0 | ||
| Summary | 0014447: Simplify Send to Playlist... structure | ||||
| Description | Currently each Send To entry contains at least 2 sub-entries: - Send to 'playlist name' - Send to New Playlist While this might be useful sometimes, it most often only means that there's one more step needed in order to send to the desired playlist. It'd probably make sense to remove the sub-menu altogether for playlists that _don't_have_sub-playlists_. Instead, a click on that menu entry would directly send tracks to that playlist. In order to be able to also create a sub-playlist, we could introduce a new playlist icon there. I.e. instead of the current: Playlist A {sub menu icon} there would be Playlist A {new playlist icon} Note that for simplicity we might even consider to NOT include the New Playlist icons and thus not support this action over Send-To menu. | ||||
| Additional Information | Reported at http://forum.mediamonkey.com/viewtopic.php?f=30&t=88586 (definitely not for the first time). | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2220 | ||||
|
|
Fixed in build 2081. |
|
|
verified functionality in 2215 New playlist icon is shown if destination Playlist do not have sub-playlists and It is added as new option if sub-playlists exists. Can you please triage. I wonder if we can further improve this by: 1. add new icon also on playlists that have sub-playlists before > sub-playlists arrow and beside it is persisten for rest of context menu we eliminate New Playlist line completely as it is bit confusing 2a. Increase delay before sub-playlists are open/shown (as it can lag ui a bit during loading sub-playlists) 2b. Make Sub-playlists open only either on click/tap(for touch mode) to > or expand/show sub-playlists when mouse enters > object only as I think it would make UI response more fluent and unify Mouse and touch behavior. |
|
|
1. I don't understand the suggestion. Perhaps a graphic would help. I wouldn't recommend removing the New Playlist function (I use it often). 2a. Wouldn't increasing the delay make the ui lag more?! 2b. Can you provide an example of a UI that works this way so that I can better understand what you mean? note: all of these issues seem to be minor tweaks so I'd suggest closing this bug and opening a new one as we're not going to be making additional changes for 5.0 unless they're severe problems. |
|
|
1. The idea is to move the 'New Playlist' function one level up, as an icon next to the previous level playlist title. I think that both approaches are ok, so let's leave the current one for now. 2. If there's a performance issue, we should rather fix it, than to make workarounds. I haven't observed it, but Michal, isn't there anything synchronous, that could block opening new items while an older submenu is still opening? |
|
|
2) we do not expect so many items in menus (in this case many hundreds of playlists), it is hardly usable menu then, even if we would implement better canceling and menu generation in more steps (current problem is generating more than 2 thousands menu items, it affects UI responsiveness). |
|
|
GUI lagging fixed in build 2220. 1) left as it is. |
|
|
Verified 2220 GUI Lagging Fixed, Closing issue. Maybe UI opening is even bit too fast. |
