Support and General Use > User Interface and Voice
Customize time to hold "play" before shutdown? (iPod 5G)
copiesofcopies:
--- Quote from: Llorean on March 21, 2008, 04:04:48 PM ---Briefly pressing the button Pauses playback, there's a significant difference between that and stop (clearing playlist, freeing audio buffer, etc).
--- End quote ---
I see. Is there a design/technical document explaining why this behavior is desirable frequently enough to justify binding it to "moderate play"?
--- Quote ---For users who routinely use the hold switch attempting to stop music, making the shutdown time shorter still makes the increase of accidental shutdowns likely.
--- End quote ---
I don't follow. I mean that I turn "hold" on when the iPod is in my pocket, so I cannot accidentally press buttons.
--- Quote ---Apple's software doesn't actually shutdown.
--- End quote ---
Ah. Is this functionality difficult to replicate in Rockbox? Or was it just considered undesirable?
--- Quote from: BigBambi on March 21, 2008, 04:15:08 PM ---Customisability is great for most things, but we really want to keep away from customising buttons. Customisable buttons = support nightmare.
--- End quote ---
This is certainly understandable. However, the Rockbox developers have also made some controversial choices (or at least choices that are unlikely to be universally loved) in this area. It would be nice if it was at least possible for popular alternate key binding "themes" to be built in so that users could have a few choices (e.g. something more like the Apple functionality). I realize that this is a complex problem to solve, but for a user who really dislikes a commonly used keybinding (like myself), it seems the only option is forking.
Llorean:
Simply put, "stopping playback" is the only way to free up the audio buffer. Some plugins need to use the audio buffer to provide enhanced functionality. As well, stopping playback makes the current playlist inactive, so that if you use the "Insert" function, a new playlist is created instead. I don't know about you, but I know many people who make use of this second feature very frequently. As well, the "stop" function should in fact be usable from the filetree and menu, quite unlike "pause."
My point with the "hold" switch thing is that you don't have hold on when stopping music, anyway, and the "accidental" is if they hold stop merely a little too long, it could shut down if the time is shortened.
Multiple keymaps are, frankly, both a support nightmare and a nightmare for people who are coding new features and need them to function reliably on multiple targets. If holding the play button a few seconds longer is significant enough of a problem, in those maybe 30 seconds you waste every day on it, that you're willing to spend several minutes every day compiling and maintaining an alternative "forked" version for yourself, well, who'm I to stop you?
copiesofcopies:
--- Quote from: Llorean on March 21, 2008, 04:33:42 PM ---Multiple keymaps are, frankly, both a support nightmare and a nightmare for people who are coding new features and need them to function reliably on multiple targets.
--- End quote ---
I cannot claim to be experienced with the codebase, or to have considered this particular issue in depth, but would it really be impossible to abstract generic functionality from specific key bindings such that people coding new features could concern themselves solely with the functionality and ignore the bindings?
--- Quote ---If holding the play button a few seconds longer is significant enough of a problem, in those maybe 30 seconds you waste every day on it, that you're willing to spend several minutes every day compiling and maintaining an alternative "forked" version for yourself, well, who'm I to stop you?
--- End quote ---
I'm sorry if you feel that I've attacked you. No, I don't think that this is the only problem with Rockbox, and yes, the sum of the problems I have are sufficient to make me wish it was capable of working differently. It seems odd to me that someone involved in a free software project would be so defensive when a user inquires about changing the program's functionality. But regardless, your answers were helpful and I appreciate you taking the time to help.
Llorean:
The keymaps can be abstracted. To a point. But different hardware has a different set of available keys. Some functions get left off entirely because there's simply not a place to put them. For example, if you were to remove the "Stop" function entirely, other parts of the software would work unexpectedly for you because that action was missing. They may not be areas you use yet, but when you tried to use them you might not realize your keymap change was at cause, and we'd have to go through the bug report process, spend forever trying to hunt it down, finally find from you that you'd changed the keymap, and then point out that by neglecting to assign a new key for that function (or by not realizing that it reassigned the key in other areas) you'd caused your own problems.
The Rockbox keymap is designed as the Rockbox keymap, not as an effort to please or match the iPod keymap. It uses the buttons in what was deemed the best way to access Rockbox's functionality on the iPod hardware, and based off of Rockbox, as a software, and off of general UI wants that have helped define the keymap both here and on other hardware. If there were a power button on the hardware, it would have a shorter time, as there is not the button has to share space with other functions.
And my response was to the fact that you made it sound like you were suggesting forking over such a trivial matter. As I'm sure you know, a "fork" is often considered a very serious matter, and usually people go through a lot of effort to avoid one, and try to come to terms first. The fact that you mentioned it in such an early post of yours seems like you're making idle threats over trivialities. Frankly it sounded like you were trying to wield the word as a threat or other means of getting your way on this single matter.
copiesofcopies:
Your point about keymaps and missing functionality is well taken. But it seems like this concern could be heavily mitigated if keymaps, instead of being fully customizable by the user at runtime, were treated like every other feature--proposed, coded, thoroughly tested, and integrated once the issues were ironed out.
I suppose it was bad form to bring up forking, so I apologize for using a loaded word without further explanation. I'm not threatening to fork--I have neither the time nor sustained interest to attempt it. And I'm not trying to bully you into changing Rockbox for a single user's issue.
But there's sort of a big question here--like you say, Rockbox's keymap is determined to some degree by 1) the need to run it on many devices, and 2) the need to accommodate /all/ of Rockbox's specific functionality. Obviously there are huge advantages to a multi-platform solution, because it increases your pool of developers. And different features of Rockbox's broad functionality appeal to different users, and by scratching lots of itches with one package Rockbox casts a wide net for potential users. But I do think the fixed keymap is very much a cost associated with these features/design choices. And I don't think it's controversial to say that there may be room in the free firmware space for a program that makes different tradeoffs--e.g. fewer features (or burying the accessibility of some features) in exchange for more flexibility in keymaps.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version