View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0017560||MediaMonkey 5||Main Panel||public||2021-02-15 19:53||2021-05-10 16:33|
|Summary||0017560: Add "Lock Tab" feature|
|Description||User has requested the ability to "pin" (lock) tabs to certain functions/nodes, such that when you click on a different node in the media tree, it won't change.|
Here are the requirements that I imagine in the feature:
1) Right-clicking on a normal tab includes a "Lock Tab" item with a closed lock icon, and right-clicking on a locked tab includes an "Unlock Tab" item with an open lock icon.
2) Locked tabs cannot be closed, and do not have a close icon.
3) Clicking on a different node when a tab is locked will open a toast message, saying "This tab is locked. Right-click on the tab to unlock it."
4) Clicking "Close Other Tabs" and "Close to the Right" will not close locked tabs
5[?]) When a tab is locked, all other items in the media tree become:
5a) disabled (grayed out)
5b) not hoverable (this will require a tweak to the skins, I believe)
6[?]) Locked tabs always appear to the left of normal tabs (as if pinned)
6a) Locked tabs can be reordered amongst themselves, like with pinned tabs in Edge or Vivaldi.
7[?]) When clicking on a node which already has a locked tab opened to that node, it switches to the locked tab instead of opening said node in the current tab.
5) and 6) could be omitted, but I believe items 1-4 are necessary for the feature.
7) is up for discussion; I'm not sure how that would work if someone wants two locked tabs with the same node.
|Tags||No tags attached.|
|Fixed in build|
||I would suggest using the 'Pin tabs' terminology that most users are accustomed to, and that it behaves like a pinned tab in most browsers (i.e. the user can switch nodes (urls) BUT double-clicking on the pinned tab OR restarting MM causes the pinned tabs to revert to the node they were pinned to). This would eliminate requirements 3), 5), 7).|
I forgot to link the original thread in the description. My interpretation of their request was that they specifically want the tabs to be associated with certain functions (e.g. Duplicate Content or Now Playing). This would make it differ from normal pinned tabs in browsers, which is why I suggested the different name.
Also, we already have a pinned item feature in the media tree, so it could cause confusion if two different features had the same name.