View Issue Details

IDProjectCategoryView StatusLast Update
0014447MMW 5Playlistspublic2020-01-15 01:43
Reporterjiri Assigned To 
PriorityhighSeverityminorReproducibilityN/A
Status closedResolutionfixed 
Target Version5.0Fixed in Version5.0 
Summary0014447: Simplify Send to Playlist... structure
DescriptionCurrently 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 InformationReported at http://forum.mediamonkey.com/viewtopic.php?f=30&t=88586 (definitely not for the first time).
TagsNo tags attached.
Fixed in build2220

Activities

michal

2017-10-11 12:40

developer   ~0048934

Fixed in build 2081.

peke

2019-11-28 01:01

developer   ~0055517

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.

rusty

2019-11-28 18:19

administrator   ~0055535

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.

jiri

2019-12-10 09:48

administrator   ~0055623

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?

michal

2020-01-08 10:00

developer   ~0055822

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

michal

2020-01-08 12:22

developer   ~0055824

Last edited: 2020-01-08 12:23

GUI lagging fixed in build 2220. 1) left as it is.

peke

2020-01-15 01:43

developer   ~0055849

Verified 2220

GUI Lagging Fixed, Closing issue.

Maybe UI opening is even bit too fast.