playerctl: apply button options selectively#2325
Conversation
2f41327 to
e1e9caf
Compare
0f8014a to
811bd30
Compare
811bd30 to
c6ce4a3
Compare
|
Thanks @lasers ; that PR will break users using the module with default settings for ages. Could we make it to actually respect the user's setting instead of resetting everything to None like this? I'm confused. |
|
User requires User gave it a random number as a workaround/solution. This can happen with any modules with default buttons. This one just has the largest button choices. Do we suggest users to assign default buttons with something else first? My approach for this module with that many button choices was that there are no default buttons anymore and users just assign what they want to use. Happy to hear your suggestions/solutions. |
|
I understand but I'm also wary of breaking something being used seamlessly by possibly a large number of users vs one having a specific case even if it's indeed not smooth for her/him. In this case my favored approach would be :
Does it make sense mate? |
c6ce4a3 to
60817ec
Compare
|
OK. I added a commit. I like the first one. It's more neutral in the long run. I think it also could lead to users having The second one contains your favored approach. Just more P.S. This kind of button code validation could be applied to all modules with buttons in the eventual future, just not in modules themselves. It'll do for now. |
60817ec to
0a3f0c6
Compare
|
I think the second and current one is my favored yes |
0a3f0c6 to
914322d
Compare
914322d to
3843ecf
Compare
This clears out the default buttons.
I initially don't know whenever to leave
button_play_pausealone... or to let users configure that themselves. If we leavebutton_play_pauseat default, then an user can run into same problem with a different button. It is more clean not to assign any default buttons.And this checks for duplicate buttons too.
/cc notifying @jdholtz author on buttons
Closes #2324