Rockbox Technical Forums

Support and General Use => User Interface and Voice => Topic started by: markun on April 28, 2007, 12:17:17 PM

Title: changes to the Gigabeat button mappings
Post by: markun on April 28, 2007, 12:17:17 PM
I changed the button mappings yesterday and basically switched POWER and A to prevent accidental shutdown when holding POWER to do a key combo (for doing a pagedown for example: POWER+DOWN).

Now I'm not so sure it was the best solution. Someone suggested we could also fix it by making A the shutdown button and leaving the layout as it was before, but I though it was a bit weird because that's what you would expect from the POWER button (because of the icon on the button)

So, what are your opinions on it?
Title: Re: changes to the Gigabeat button mappings
Post by: Llorean on April 28, 2007, 12:23:15 PM
I think the idea to make one button turn it on (the button labelled "Power" on the unit) and a different button turn it off is incredibly counterintuitive.

People who don't like the possibility of their button maps being changed shouldn't use pre-release software.
Title: Re: changes to the Gigabeat button mappings
Post by: copskid44 on April 28, 2007, 01:06:36 PM
I think he has something.

POWER
Turn On - Hold
Menu

A Button
Mute and move to menu
Turn Off - Hold

Title: Re: changes to the Gigabeat button mappings
Post by: johnson4 on April 28, 2007, 03:47:44 PM
 Thank you Thank you Thank you
I was so annoyed by the accidental shut-down, this is much better.
My biggest problem was with moving the cursor in the text-editor, I'm very thankful
Title: Re: changes to the Gigabeat button mappings
Post by: copskid44 on April 29, 2007, 06:30:12 PM
what! ive never accidentally shut my gigabeat down! I maybe am stubborn but I still hate it.

Could someone make a patch to where it changes it back so I dont have to change the code every time i update?
Title: Re: changes to the Gigabeat button mappings
Post by: markun on April 30, 2007, 05:26:18 AM
If you've downloaded the source with svn it's very easy to make your own patch. After changing it the way you want, you go to the root of the source tree and do "svn diff > old_buttons.patch".
Title: Re: changes to the Gigabeat button mappings
Post by: mannequin on April 30, 2007, 12:59:42 PM
markun,

thanks for the changes. it was very uncomfortable to page scroll or use the text editor with the old mappings due to the accident shutdown issue.

however, we have the VOL buttons idling most of the time. wouldn't it be a good idea to use them for page and text editor scrolling?
Title: Re: changes to the Gigabeat button mappings
Post by: johnson4 on April 30, 2007, 01:30:26 PM

however, we have the VOL buttons idling most of the time. wouldn't it be a good idea to use them for page and text editor scrolling?
I like the sounds of that too
Title: Re: changes to the Gigabeat button mappings
Post by: lights0ut on April 30, 2007, 02:56:03 PM
I just got an F40, but I've used both buttonmappings, I like the new one better because it seems to be more intuitive. I don't use the paged list scrolling function because I have my music quite organised, but if I did, I could see where I'd get the accidental shutdown (database browsing, right?). I always thought the power button shouldn't be used to go back to the filebrowser/wps, that's not what a power button does.
Just my thoughts, and thanks for the changes. ;)
Title: Re: changes to the Gigabeat button mappings
Post by: Nate! on April 30, 2007, 03:43:03 PM
Ooh, good idea.  I second or third that request to use the VOL rocker for paged scrolling and text editing.
Title: Re: changes to the Gigabeat button mappings
Post by: lights0ut on May 01, 2007, 11:27:17 PM
Doesn't having the vol. buttons always on volume function mean that one could change the volume from anywhere on the player? I like this functionality, but I could see where using the vol buttons as paging scrollers it would aid those with very long lists. Maybe a new setting is in order?
Title: Re: changes to the Gigabeat button mappings
Post by: Mad Cow on May 02, 2007, 08:22:07 AM
I changed the mappings to have the volume buttons for paged scrolling a while ago because it was similar to how the H10 does it. IMO it's much better than using them to change the volume from the menus.
Title: Re: changes to the Gigabeat button mappings
Post by: ilikedirt on May 15, 2007, 08:52:05 AM
I don't quite like the new mapping. It makes using the player with one hand a whole lot harder and pushing the A button when the player is in the dock is fiddly too.

I did not know, that the page-scroll was on power-up/down so I never experienced accidential shutdowns - but now that I know that would propably be a problem with the old layout ;) So I do not know, what would be the best solution, either, but I still prefer the old layout.
Title: Re: changes to the Gigabeat button mappings
Post by: Llorean on May 15, 2007, 08:54:25 AM
I'm still of the opinion that in the WPS, A should be play/pause, and 'select' should go back to the filetree. It brings back easy (easier at least) one handed operation, and brings the target in line with the other targets in regards to button map consistency between screens.

With that, you can then, from WPS, using only the cross, insert and manipulate the playlist. Getting back to the WPS is slightly harder (Hold left, then tap left once, then choose the Now Playing entry) than a single button press, but you get the added functionality, and the cross-platform consistency of not having a button change functions between screens (change functions relative to the other targets, that is).
Title: Re: changes to the Gigabeat button mappings
Post by: Nate! on May 15, 2007, 10:03:04 AM
Now I understand.  Uniformity is the desired goal.  I was thinking what Llorean described was an attempt to get the Gigabeat to behave like the iriver platforms.  This didn't seem right since some of the Gigabeat community have only had the Toshiba device and have grown accustom to its navigation style.  (Hence my feature request for the addition of the sliding cross navigation.)  But, I for one, do admire how Rockbox works for a miriad of platforms and Rockbox on one device operates much the same way as Rockbox on another.

Like I've mentioned before, the new mapping took just a few minutes to get used to so changing it again wouldn't be a big deal.  (For Me anyway)

Although, can we get a dev to revisit the sliding cross navigation feature request? ;) lol
Title: Re: changes to the Gigabeat button mappings
Post by: AlexP on May 15, 2007, 10:09:09 AM
I completely agree with Llorean.  In the past I argued for swapping power and select in the WPS to make it consistent between screens.  I'm not bothered which button is labelled what (i.e. say button 1 is play on iRiver and A on gigabeat, button 2 is A/B on iRiver and menu on gigabeat etc.), I just think that the usage of button 1 (and button 2 ...) should be consistent.

Now that power and A have essentially been swapped, select and A should be swapped in the WPS to have consistency between what each button does across different screens in rockbox.
Title: Re: changes to the Gigabeat button mappings
Post by: markun on May 15, 2007, 10:39:51 AM
The Archos Player (didn't check the other targets) has 1 button (the "on" button) to go from the WPS to the file browser and from the file browser back to the WPS. Should that be changed as well to make it more consistent with the rest?
Title: Re: changes to the Gigabeat button mappings
Post by: bascule on May 15, 2007, 10:40:36 AM
Llorean, I absolutely agree with your proposal. If my gigabeat was like my iriver, using the centre cross (joystick press on H1x0) to access the browser, I would get my fingers much less in a twist. The A button is just too low down for one-handed use.

...Getting back to the WPS is slightly harder (Hold left, then tap left once, then choose the Now Playing entry) than a single button press...

But wouldn't the A button (play/pause) take you back to the WPS as per other targets?
Title: Re: changes to the Gigabeat button mappings
Post by: Llorean on May 15, 2007, 10:51:20 AM
Yeah, I personally have this general opinion on button maps:

1) Rockbox shouldn't ever go out of its way to match the other software beyond acknowledging that buttons are labelled, such as "Play", "Stop", "Menu", etc.

2) Rockbox should attempt, where the number of buttons permits, to respect Rockbox's own button mappings on other platforms, so that for example the button labelled "Menu" does the same thing on the same screen independent of which hardware you're holding. This way someone who's used Rockbox before can pick up a new target, and other than the positioning of the buttons, know what they'll do in any given screen once they've learned which button is which for any one screen.

That's my personal philosophy on pretty much the whole matter. :)
Title: Re: changes to the Gigabeat button mappings
Post by: AlexP on May 15, 2007, 11:29:29 AM
Llorean has just put what I was trying to say much better.  I agree with him!
Title: Re: changes to the Gigabeat button mappings
Post by: ilikedirt on May 15, 2007, 05:33:31 PM
I'm mostly interested in a as-good-as-possible one handed operation. So I'm all for iriver like navigation (select takes to browser).
Title: Re: changes to the Gigabeat button mappings
Post by: Llorean on May 16, 2007, 02:51:33 AM
Yes, the A button would take you back to the WPS, I was just talking about within the context of one-handed, I think going to the "Now Playing" menu entry is slightly easier than hitting the A button (unless you're left handed like me).
Title: Re: changes to the Gigabeat button mappings
Post by: lights0ut on May 19, 2007, 06:04:50 PM
I wouldn't mind the switch of A and centre tap for going to the file browser.

I was thinking about the paged scrolling with the vol +/- buttons, I know paged scrolling is achieved by holding A, but it would be quite nice to use the vol. buttons because it would be quicker, and I now agree that the loss of the ability to change volume in the menu is not that big a deal.