Rockbox

I mean the Right button not the left button.

Out of curiosity, is it worth it to add size to the code for Queue and Play and Insert and Play since those can very very easily be accomplished with the Next counterparts and a tap of the next track button?

There are very strong arguments for not adding unnecessary things to the core, so I'm just curious if an extra button press or two is really worth adding that code.

Sure if we had the possibility to change the action of the right button while having a song selected, but now if I do press Navi on my H300 or the right button it creates a whole new playlist instead of just adding it to the current playlist. While sometimes I do want that, there are times where I wish I could skip the part of opening the context menu to add a few songs to my queue or to my playlist.

I thought your alternative suggestion was more option in the context menu... And I was only asking about those context menu options. I mean, you'd have to open the context menu to get to those too, so I don't understand your response.

Well as I said if we could change the action of those buttons mentioned above, we wouldn't need to bloat the context menu as you claim it does. So if the right button would function as mentioned in the request's name, we wouldn't need to expand the option in the context menu.
I have been opening the context and queueing a song, then exiting the fileviewer and skip to the next song since RB added this function and I can live with it, but I just find that these steps could be skipped.
On the other hand, if my idea/concept on being able to change the action of certain buttons would be approved we would not need this.

Look, fine, if you're not going to answer my question, that's okay. I did not say *anything* about the first part of the idea. I just asked how the Queue and Play is a good alternative, since all it saves is one button press, at the cost of code size?

Both options of my request lead to the same result, to shorten a job. The first alternative is a bit more complex which gives a better result (less clicks), the latter is certainly simpler and leaves me with more clicks.

Dark one, we are not talking about massive ammounts of code here. We are talking about one menu option that would prevent having to reload a playlist every time you accidentally bump the navi button twice.

Yes, it is only a couple extra clicks to insert a track, but it is frustrating when the default behavior should not be to destroy your playlist. Its not the action we want to change really, its the result of the action. I understand some people like this behavior, others don't. Users should be free to change this action according to their needs.

Also, it allows for more customization and freedom. Two things that i have come to respect from rockbox.

I too, want to keep the code trim and lean, but not at the cost of useability.

You're still missing my point entirely. I said NOTHING about the configurability of the default behaviour being bad.

All I said is that it seems "Queue and Play" and "Insert and Play" are not a good alternative if it doesn't get accepted, because they add code and in the end save I believe one, or MAYBE two keypresses.

i guess i am missing your point. I believe that it should be harder to destroy a playlist than to create one. If you're worried about code size, maybe the default action of the button should be changed. It is silly to remove a playlist because you bumped the wrong button.

But, i think both ways could come in handy. It just happens that the default way is less convenient. Thats why i think this should be toggle-able. We are not talking about gigs of code.

Not directly related to the request but, if you would like to be prompted before a playlist you've created is "destroyed", enable the "Warn When Erasing Dynamic Playlist" option from the playlist menu.

The only reason i didn't file this behavior myself as a bug is that i know it was intentional.

hardeep... that doesn't eliminate the problem, just adds another prompt

thanks for the advise though.. i know you are just trying to help

The reason I say you're missing the point is because I've not said ANYTHING about the option to change the default behaviour of the button. ALL I addressed is the second half of the post, where you offered an "alternative" that increases code size to save ONE button press. I addressed the alternative, not the main part of the idea, but every single one of your responses has acted like I addressed the whole topic. You've been defending an idea that I have not said anything about, and have not spoken once in defense of the latter half, which is what I spoke about.

On a related note, there's also the handy dandy party mode. Which causes the track insert last rather than reinitializing the playlist to be the default action. (See, there, I finally spoke about the first half.)

Well, changing the default behavior is the less politically correct way to ask. That is saying, "Everyone change." I don't care if EVERYONE has my opinion, that's why i want it to be an option. Convenience.

Admittedly, the default behavior could be handy AT TIMES, just not most of the time for me. So, thats why i've been presenting this as a toggle.

Party mode, is worse than default. Because: A) it makes it harder to load a playlist B) it queues selected file Last instead of playing it, so you STILL have to go back in and reinsert the track.

However, i don't think party mode should be removed because i don't find it useful.

I understand why i asked for the feature in the way i did. I hope you do too now. I didnt think about proposing a change to the default because i'm not sure the majority want it that way. I can see how it would be preferable, but like i said... i don't know what the majority's view is.

You've still missed most of what I said. I'm going to drop it now because it's rather clear you're getting what you want out of my posts, rather than actually reading what I'm saying. I've said very clearly which part of your topic I'm addressing, and you may also notice I never said "changing the default behaviour" but rather "option to change the default behaviour of the button" which, is what you proposed. A menu option that changes what the button does.

So please, in the future, pay attention to what someone actually says, rather than making the assumption that they're against your idea. I only addressed the second half, but all your responses have been in defense of the first half, and then when I make reference to the first half you assume I misunderstood it because you didn't take the words I put down literally, or assumed I meant something other than what I wrote.

Okay, a quote from you.

"Out of curiosity, is it worth it to add size to the code for Queue and Play and Insert and Play since those can very very easily be accomplished with the Next counterparts and a tap of the next track button?"

YES! I think it is worth it. The number of responses defending the idea, and the reasoning behind it should allow you to assume that it is worth it.

You:
"thought your alternative suggestion was more option in the context menu... And I was only asking about those context menu options. "

I would like the option located in general settings -> playback if that is what you mean by context menu

you:
"I just asked how the Queue and Play is a good alternative, since all it saves is one button press, at the cost of code size?"

This is the part that triggered my defense of the behavior. It saves more than one button press and i'm willing to increase the code size slightly to offer what i want for functionality. It seemed to me like you were against the idea.

It is not just one button press that it saves, its the playlist (accidental button press deletes your playlist). Its playing the track that you want, when you want to (why party mode is not the same). It is playing a track, when you hit play (not a prompt asking you if you want to blow away your play list)

Did i miss any questions/part of your response?

Okay, I see where the misunderstanding is. The Context Menu is the menu that pops up when you hold Select or Navi on a file. So, remembering that, look back to what you originally wrote. If it's added to that menu it saves one button press compared to the "Queue Next" and "Insert Next" options already there. I responded to what literally you wrote, and am not responsible for the fact that you apparently don't know which menu is the "Context Menu"

Ok.. now that i understand what you are asking. Here is what i'm experiencing.

I hit the navi button to get into the file browser, some times there is lag before it gets to the file browser. So, i hit the navi button again (thinking that i didn't press it before or didn't fully depress it). Call it a patience problem, whatever, it still happens.

As you know, This throws away your current playlist, and creates a new playlist with only the files in the current directory. In order to play files outside of the current directory, you have to hit the file browser, navigate up 2-4 directories, click down to the menu option to find your playlist in root, then select the playlist. This is where all of the extra clicks come in.

So, while it is only one extra button press when you do things right, it is like punishment (several clicks) when you screw up (i do that often enough, and i assume others do too).

I understand that rock box can't always be instant, so i was just trying to propose a way to work around my impatience/accidental clicks.

One other thing i missed. The context menu does not allow you to play now. What happens is you insert the track next, then you have to go to the now playing screen. Then advance to the next track. So technically there is additional clicking involved in the front end that i failed to mention, not just when you screw up. I can deal with this when i do things right, because it doesn't cause me to load a new playlist.

Would be easier if the thing had A.I. and could read my mind, but i realize that THAT amount of code would be crazy. ;)

Yes, I know that the context menu doesn't "play now", and which is where the original "one or two button presses" came from. I simplified it to one later, but I realize it is two because after inserting you don't go back to the WPS, and I was assuming that you would choose to go back to the WPS after a play now. (Basically, if you go back by hand after an Insert and Play it saves one button press. If you leave the file browser open after an I&P then it saves two button presses.)

Yeah, and i realize, 1-2 button presses is a technicality. But, you have to do this EVERY TIME. That's where it can become inconvenient to users like me.

If you do something a lot, like every time you change a track to one that you would select. 1-2 extra clicks can become a big deal if you have to do them EVERY TIME you want to perform a function. Espesially, when that's the only way you want something to behave essentially. Inserting into the Queue can be handy, but really, for me, it is the side feature. I would much rather just be able to play the song i picked.

It also eliminates the problem of your player being in your pocket, and you bumping the navi button 2 times. Forcing you to requeue.

For me, It would make the player 100% better. I don't know what value tboy assigns to it, but he must think it was worth the time to post. There have been other requests for this feature, so i am not alone in wanting this. As you saw, someone even took the time to attempt to develop a patch.

I don't think of this as a "frill." I think if this as core functionality.

You still missed that I was only responding to the extra context menu options with that one. *sigh*

I didn't miss anything, just doing some further explaining about how 1 extra click is not just one extra click.

I realize that picking the song takes you back to the wps, it should. I just dont want to reload the playlist afterwards.

So, i don't really care how many clicks it saves or doesn't save (as in an exact number), but it will save a lot in reloading the playlist.

I don't want a context menu option for insert and play, because that wouldn't fix my issue with the playlist. I would rather just have a default value setting, which is what i believe i asked for. If it wasn't, its what i'm asking for now.

You offered as an alternative a context menu option. Which is what I responded to. So yes, it is exactly either 1 or 2 button presses saved with the context menu option you had described. And Insert and Queue would neither clear a playlist. They don't now.

Paul, I did respond to your question. I said I hope to gain the same thing from these two features, one saves me more clicks then the other.

Again, you got me on a technicality. The current playlist is no more when you select a track, a new one is created. But i don't want that to happen.

I'm not trying to "get" you on anything. All I've been saying is that I don't think the alternative idea, as you originally described it, will be worth it since it saves 1, and at very most 2, clicks. The first idea I actually think is a good one, it just seems to me that if it doesn't get accepted, the alternative as you originally described it is virtually worthless since it increases size for a 1 or 2 click savings.

Perhaps we should consider the approach that Cowon has, where a short click on the joystick pops up a menu where you can choose between the various play/queue options.

What about my initial request, the first configurable action? Is that a sensable addition to RB?

linus, isn't that what we have essentially now? I mean, there isn't a play now, but if there was, it would not solve my problem of accidentally bumping the navi button twice, causing me to reload a playlist.

Unless you mean that we could hit left nav to queue and play a song. Currently the track isn't put into current playlist. I want that instead of having the player make a new playlist. Since this would change the behavior of rockbox greatly, i think first configurable action is the way to go. I can see myself wanting different behaviors at different times, but the majority of the time (to the tune of 90%), i would want selecting a track to queue and play. Instead of replacing the current playlist with a new one (made of the current directory).

In the default cowon firmware, if you pick a track from the file browser, it plays a track and doesn't queue the current dir. Really, thats what i'm going for. Changing the button mapping is just the only way i can think of to make the player behave the way i want.

I realize cowon has a different approach to playlist management. They have an option to restrict shuffle to current directory or to the whole playlist. Because of how rockbox is set up, this is not really possible. Changing the default first action would allow for essentially the same thing to happen in the end.

Rockbox is better than cowons firmware in a majority of ways. To be honest, this is the only area i've found where cowon has an advantage over rockbox. I was thinking that this change would make rockbox better than cowon's firmware in every way except video. (Video being a non issue for me, so it would make rockbox better in every way for me.)