Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lock menu & sync menu #827

Open
NohWayJose opened this issue Jun 9, 2024 · 5 comments
Open

Lock menu & sync menu #827

NohWayJose opened this issue Jun 9, 2024 · 5 comments

Comments

@NohWayJose
Copy link

Sorry, I'm being lazy and putting two related feature requests in one issue.

  1. In Player's drop down menu please add a toggle to lock the menu, so long press will no longer move an item to or from the Archive folder
  2. In settings, add a check box to make the menus for all the players the same, based on selection from a drop down to choose which player to use as the template. Also, check box for lock menus, so further edits are blocked. If lock is off but menu sync is on, edits to one becomes edits to all. If lock is on and sync is on, no changes are permitted. Turning sync off (grey out the dropdown) means subsequent edits are only applied to the currently selected player
@kaaholst
Copy link
Owner

If I understand correct, something similar is already possible. In settings for archive and shortcuts, you can select to deactivate long press, but current archive/shortcuts. This will effectively lock your selections, i.e. prevent from accidentally long pressing an item.

Before locking, you will have to set up your menu, for each player. Since some items are only available to some players, these settings have to be per player. We get the items from the server, which will return different items depending on the player.

@NohWayJose
Copy link
Author

Thanks @kaaholst
I found that setting but (speaking as a UX designer) it's a bit confusing. I disabled but kept the archive. I could still long press some menu items and they'd be removed. Some couldn't but it's not clear why.

Putting the request 2 (synchronizing menus) to one side, I think what you propose is only a partial answer. A simple 'lock menus' in the top level ... menu, reliably locking all elements in the menu, would be much more usable.

@kaaholst
Copy link
Owner

I'm not able to reproduce your issue, are you sure you deactivated both archive and shortcuts?
You find those 2 settings in the “Shortcuts etc.” section as “Archive” and “Shortcuts” respectively.

I think that the relation between a “lock menus” setting and the Archive and Shortcut settings would be confusing. I'd prefer to fix the confusion arising from those two settings if possible, rather than introducing a new setting. This could e.g. be by changing the wording from “Disabled, but …” to something involving the word locked. I'm also open to combining those two settings into one, if you have any suggestion which would make this understandable.

Actually, I think the basic confusion stems from understanding what can be archived, and what can be a shortcut. E.g. items in My Music can be archived, but items in My Apps can be a shortcut. It is decided by the server, and documented here Home Menu Items versus SlimbrowseItems.

Finally, could you elaborate what “Player's drop-down menu” is, and which menu would be locked by “a toggle to lock the menu” (LMS refers to all pages as menus).

@kaaholst
Copy link
Owner

One idea comes to mind.
How about having items on the main screen can be archived, and all others can be shortcut?
Regardless if they are Home Menu Items or SlimbrowseItems in the LMS sense.

@NohWayJose
Copy link
Author

I'm going to try to describe what's happening as if there was only one checkbox in settings and it's called 'Edit interface'. It would need to have a text description area:
When selected - "long press allows items to be moved to the home page or archived from the home page (or returned to their native place)"
When unselected - "long press is disabled so the home screen is not modifiable"

There may be better wording, particularly for 'enabled/selected' but combining the two settings and describing each state in greater detail could help. What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants