Customize time to hold "play" before shutdown? (iPod 5G)

[copiesofcopies]

Is there an option to adjust the length of time the user must hold down the play button (on an iPod 5G) before shutdown initiates?  I haven't been able to find one.  The default length of time is frustratingly long for me.

Thanks!

[Llorean]

No, for two reasons:

1) Moderately long play stops playback, really long play shuts down.
2) Prevents accidental shutdown as easily.

[copiesofcopies]

1.  Briefly pressing the play button also stops playback, so it seems unnecessary to duplicate this functionality for moderately long presses.

2.  For users who routinely use the hold switch, preventing accidental shutdown is not an issue.

Given the above, and Rockbox's emphasis on customizability, why not make this at least an option, with the default set to the existing behavior?  After all, this is how Apple's proprietary software behaves, and I haven't noticed a major outcry over accidental shutdowns.

[Llorean]

Briefly pressing the button Pauses playback, there's a significant difference between that and stop (clearing playlist, freeing audio buffer, etc).

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.

Apple's software doesn't actually shutdown. It merely goes into a low power mode when you do that. So, accidentally shutting down the Apple firmware requires significantly less disk access than accidentally shutting down Rockbox (and thus less battery).

[AlexP]

Given the above, and Rockbox's emphasis on customizability, why not make this at least an option

Customisability is great for most things, but we really want to keep away from customising buttons.  Customisable buttons = support nightmare.

[copiesofcopies]

Briefly pressing the button Pauses playback, there's a significant difference between that and stop (clearing playlist, freeing audio buffer, etc).

I see.  Is there a design/technical document explaining why this behavior is desirable frequently enough to justify binding it to "moderate play"?

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.

I don't follow.  I mean that I turn "hold" on when the iPod is in my pocket, so I cannot accidentally press buttons.

Apple's software doesn't actually shutdown.

Ah.  Is this functionality difficult to replicate in Rockbox?  Or was it just considered undesirable?

Customisability is great for most things, but we really want to keep away from customising buttons.  Customisable buttons = support nightmare.

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]

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.

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?

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?

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.

[AlexP]

Put plainly, customisable keymaps aren't going to happen.  However, it is very simple to change the mapping in the code then compile, and we would be happy to help you do that if

a)  You want to,
b)  You need help.

[Llorean]

Ah, yes, there certainly is room for such a thing in the free firmware space. But, Rockbox already is a different thing, and isn't likely to pick up and change the whole direction of the project to become another thing.

Basically, the people who already work on Rockbox do so because of what it is. Few, if any, of them will want to turn it into something different entirely (a stripped down, or less obviously functional firmware that requires more platform specific development time spent on user interfece while offering less actual or at least apparent functionality).

This begins to sound like a job for an entirely new project, to me. While we do want to see UI improvement (see the Summer of Code wiki page, it's one of the things we'd like to see) a variety of keymaps still makes it much harder for someone to predict usability and/or provide support.

[copiesofcopies]

Basically, the people who already work on Rockbox do so because of what it is.

Yeah, understood.  And don't get me wrong, I like what Rockbox is very much.  But it's also discouraging to hear that the little thing that bugs me most consistently about it, which prior to this conversation seemed like such an easy thing to fix, is in fact an intractable element of the software.  Next you're going to tell me that the text-entry screen must remain as it is forever

[AlexP]

Which text entry screen?    If you mean the virtual keyboard, you can customise that, or use morse code if you like.

They keymap issue is fairly simple for you to fix for a personal version, if you are willing to compile

[copiesofcopies]

Which text entry screen?    If you mean the virtual keyboard, you can customise that, or use morse code if you like.

I think that's what I mean.  Is that what you use to rename files?  How do you customize that?

The keymap issue is fairly simple for you to fix for a personal version, if you are willing to compile

Yeah, I'm willing.  I guess I'll have to figure out what to do with the "stop" function...

Where's the best place to start with this?