Pressing LEFT to get to WPS from file root

[Llorean]

You forget the "Not wasting binary size" camp.

*All* the feature does is adds an additional button to do something that can already be done from that screen. I can't imagine justifying increasing the binary size for that, evne as toggleable. Consider that they wouldn't even justify the binary size incrase for a choice between % and dB volume in the status bar after they changed.

[goffa]

I understand keeping rockbox trim and lean. However, i find a feature such as left to wps, or the instant queuing quite useful.    There are a great number of features that i will never use included in rockbox already.  Yes, it is true that you can click 3 times every time you want to add a song instead of one, just doesn't seem... efficient.

Do i think that they should be removed? Absolutely not. Example. I can't stand crossfade, there is much more code involved with crossfade than with these two minor patches  (minor in size, not functionality).  However, i do know that many people utilize this feature, just like i know that many people would use left to wps and the instant queuing. The patches are out, they work, they aren't huge.  

This player would cease to function if we removed everything that someone didn't find useful.  

I wouldn't use the % and dB toggle myself, but i'm not opposed to that either. There has to be a balance between functionality and trim code.  

I only suggest a toggle as a compromise. My TRUE feeling is that one click queuing should be a default action. I know that that is a MUCH tougher sell than the toggle. (Maybe i don't KNOW that, but i assume that.) Plus, you get arguments from people who like it the way it is.  You get the common "why should everyone change for you" debate, which i was hoping to avoid. Instead, i constantly run into the keep code clean at the cost of function argument.  Catch 22 i guess.

In the end, i think it's funny to argue about binary size when there are talking menus built into that same binary. Yet, we can't include another menu option because that would bloat the code. Kind of takes the logic out of the "not wasting binary size" camp if you  ask me. I guess the ones in that camp are the ones that ultimately decide the direction rockbox goes. In all actuality, i guess its their right, they built the player so they can include as much or as little as they want.  

In the end of the day, i think the player should mold to you, not the other way around.

[Yotto]

I won't take up any of your points, because in spirit I agree with them (Especially about crossfade.  Yuck) but as to the talking menus, Rockbox has a fairly large (compared to other MP3 firmwares) blind user base.  If you remove the speech support, you essentially brick their players.

[goffa]

I was merely using voice as an example. Stating that the voice feature is huge in size. I don't think it should be removed just because i don't use it.

But, by the same token its hard to preach "small binary size" when the above 2 mentioned features (left to wps, click action) don't really hinder performance or comparatively increase binary size.

I also understand that mountains are made of single grains of dirt. Meaning that you cant include EVERYTHING. By the same token, I think we can add a lot of  "single grains of dirt" before we reach mountain sized proportions or even start to affect performance.



P.S. If i had my way, voice would be a compile time option (like a yes to include /no to exclude). I realize that implementing that would require a lot of unnecessary work. So, I'm suggesting that the developers don't waste their time/energy on that. Since, because it is a menu option, i can disable the feature and not affect performance. The only difference is binary size, so the effort is not really worth the gain.

[Llorean]

The problem is, we're *already* at mountain size, as many of you seem to forget.

It is official that the Rockbox binary is too big (it won't fit in the space constrained areas that we were trying to avoid making it too big for) so now we need to DECREASE it's size, but neatening up code and such.

And unfortunately you picked the wrong feature of the two to defend. I'm in favour of one-button queue and actually stated my suggestion that it be the default action for a short tap of Rec while in WPS.

My last post was ONLY against left-to-wps because that can ALREADY be done with a SINGLE button press from the very same screen you'd press left to get to WPS. I'm sorry if you have to move your thumb 3/4 inches more, but I think not wasting binary size is worth that small of an inconvenience when the binary is already too big, and that is definitely a grain of sand our mountain can live without.

[goffa]

I guess its not REQUIRED to have left to wps, however, it does seem more natural.

Also, the code size only increases by literally  2 lines. (If you take out the comments, and don't make it toggleable)

In the grand scheme, we aren't going to gain much by leaving it out. Some users will gain a lot by having it in though.

I doubt any deciding body will be convinced by my argument, so i'll just stand in my position that it should be included and leave it at that.

Also, given the statistics that 71% of people polled wouldn't mind or would enjoy it. And 10% Don't really care. My math says that the vote is  strikingly in favor of having it included. 80/20

[AlexP]

The argument that has been used before and is to my mind persuasive is blind users.

It is much easier if you can't see the screen to press left a few times knowing you will end up in root, and can then navigate through the menu structure you can remember.  With left to WPS, one more click means you have to restart the whole procedure.

I would much rather have people move their thumb slightly (a minor inconvenience), than mess up navigation for blind users (a huge inconvenience).

[Llorean]

Yes, if it is included it HAS to be an option, and it HAS to be off by default. This is, in my mind, not negotiable due to our blind users.

So when being considered you must consider the addition of it as an option.

As well, when you're already too large, even two lines of code can seem like too much if it's a feature only in the sense that it permits people to be slightly more lazy.

[Mikerman]

Laziness is human nature and, in fact, is something that should be taken into acccount with player ergonomics, IMHO.



Having said that, if the feature has other impediments that are deemed too costly, such as code size or issues for some users, that of course should affect consideration.

At times I wish that features could be toggled on or off in the compile process.  For example, I don't use crossfade, and would much rather have left-to-WPS (I don't know why, but my hands just tend to use it instinctually).  But I can forsee many issues with this and don't offer it as a practical solution.

[scorche]

You can do that yourself by #ifdefing out all of the parts of the code that pertains to that option.  And yes, there are many issues with this.  No issues for your own copy of the source, but if it were to be committed like that.  Removing features for targets is never a good thing.

That said, there is one feature that you can disable and not compile without any side effects: Tagcache.  But that is about it with the CVS source code.

[Jonny]

Just a quick suggestion, I don't know whether or not it has been suggested before.
How about modifying the patch so that holding left will scroll to to root and stop there. and an extra left press is then required to go to the WPS. Kind of like how the scrolling in directories works at the moment, the scrolling stops at the last file of the directory and en extra press is required to begin cycling again.
I for one like to hold left when in a directory to return to the root to access playlists or pictures or to reboot. This is now impossible. I would have thought this would also simplify use for blind users since by holding left they will know that they are in the root directory.
This would likely take up more code I suppose but I agree wth Llorean thta the left to WPS must be a togglable option.

[fml2]

How about modifying the patch so that holding left will scroll to to root and stop there. and an extra left press is then required to go to the WPS. Kind of like how the scrolling in directories works at the moment

This is exactly the way I would expect it to work (if it's enabled). And if it gets integrated into the official build of course :-)

[Llorean]

Again: Why do their need to be *two* buttons that go from the filetree root to the WPS?

[fml2]

Again: Why do their need to be *two* buttons that go from the filetree root to the WPS?

Llorean, I'm probably going to say something that's been said many times (also in this thread) but it's just more convenient to some users on some players. For example, on H120 most of the actions are taken using the joystick. You listen to a song, you want to listen to another. What do you do? Press the joystick (this shows the file browser), you navigate to the other folder and then you decide to stay with the song currenly playing. You can, of course, just press PLAY (and that would be just one press) but you have to use another finger. So some people (me probably included) would compromise the number of key presses for the fact that they can use the same finger (thumb). It's just a matter of preference. It has no rational explanation.

Some users buy white iPods and some get black? Why? Because they prefer it that way. No more, no less.

[Llorean]

If it's *just* a matter of idle preference, why do people think Left-to-WPS should go in despite all the actual objections to it? If it were as simple as preference, you'd think people would simply say "Ah well, there are very strong reasons against it, or at least the core devs consider them very strong, and there's a patch for us anyway, so we'll stop pestering them about it."

I mean, you guys have been going on about this patch for ages, despite the core developers telling you very, very clearly why they do not want this feature, and you never really address their concerns instead simply saying "We prefer it this way."

That's why I asked for a reason. I thought: Hey, someone resurrected the long decided issue YET AGAIN, maybe they actually have a real reason.