Standardized Controls

[fusion_power]

I did so here, but I might not have made that entirely clear, I will edit my first post to reflect that change. For the record, that's the layout I am proposing:


B - Confirm


X - Cancel


START - Pause (in game)


Fn+Q (ESC) - Exit


Select - Exit / Menu (as an alternate to Fn+Q)


Space - Overlay menu in emulators

Looks good for me. There are still enouch other Keys free to use individualy for the program or Game. ^^


Everything is good as long as no weird, unlogic stuff is used like "START for ending Game" or all the Shoulder Button combinations to get into the Menu, we know from GP2X.

 

[Caine]

I did so here, but I might not have made that entirely clear, I will edit my first post to reflect that change. For the record, that's the layout I am proposing:


B - Confirm


X - Cancel


START - Pause (in game)


Fn+Q (ESC) - Exit


Select - Exit / Menu (as an alternate to Fn+Q)


Space - Overlay menu in emulators

Oh, that was all of it


I'm not entirely sure about select. I certainly would not advocate having it bound to instant quit functionality. Fn+Q is an uncommon enough combination which you won't hit accidentally.


So Select: in-game menu, space: emulator menu sounds decent. I like the separation between game-controls (affecting the game) and keyboard (affecting the meta-environment of the game).


I'm assuming the scope of this to be mostly targeted at homebrew games, emulators and launchers. Desktop software and pc games (e.g. dosbox, amiga) would be an exception more often than not.

 

[DaMummy]

cant we just put bans on bad controls schemes like using just q for quit for anything that uses the dpad? or using keyboard O & P for action buttons?

 

[foxblock]

Oh, that was all of it


I'm not entirely sure about select. I certainly would not advocate having it bound to instant quit functionality. Fn+Q is an uncommon enough combination which you won't hit accidentally.


So Select: in-game menu, space: emulator menu sounds decent. I like the separation between game-controls (affecting the game) and keyboard (affecting the meta-environment of the game).


I'm assuming the scope of this to be mostly targeted at homebrew games, emulators and launchers. Desktop software and pc games (e.g. dosbox, amiga) would be an exception more often than not.

Yeah for now If someone feels some function is always needed and should be included, it can still be added, but I feel, that "accept", "cancel/deny", "start/pause" and "exit" are the most common ones.


Not sure about select either, I would rather use the Pandora key for that, but I am not sure whether it can be used anywhere without side-effects.


The select key is mostly included as an alternate to Fn+Q as availability of that was not too obvious to me (and I just assume to other users) in the first few days. Also I am not sure ESC can be bound in any program (but it is preferred over Select).


Yeah, scope is anything that seems appropriate, but for now I think the three cases you mention probably make 99% of it.

 

[Caine]

The select key is mostly included as an alternate to Fn+Q as availability of that was not too obvious to me (and I just assume to other users) in the first few days.

You do raise a valid point there. Your typical console demographic would probably try the Pandora key first and start/select second for a quit operation.

 

[PokeParadox]

I support your standardised proposals... I'm not keen on the select button idea...

 

[WizardStan]

I like using the Pandora button for menu instead of select or space bar or whatever.

 

[bzar]

^ Except the pandora button does stuff in the underlying interface in both XFCE (opens menu [albeit in background], or quits applications when held) and MiniMenu (quits active application), so these would need to be changed first. I think it would make sense to make it the default "meta-menu" key (since nothing in ported etc stuff maps to it by default), but in that case we'd need to define its meaning a bit more strictly to avoid clashes. Perhaps we could have a dedicated combo for hard killing stuff, like L+R+Pandora (or something)? This would leave the pandora button free for application uses.


I see the select button as "quit dialog" or "in-game menu" button instead of direct quit button.


Personally, I support this control scheme. I just changed the buttons in my beefed-up follower for MilkyTest Panorama UI called "Consolidation" to fit this.

 

[Prometheus]

Perhaps I've missed something, but what about the case of emulators that actually use the Select button as a button of the emulated console?

 

[milkshake]

good point!

 

[Caine]

Indeed. D-pad, nubs, ABXY, LR, start, select. These should all be reserved for emulated and homebrew games.


Fn+Q has a slight discovery issue, though ESC is quite intuitive to try for desktop users. ALT+F4 (and perhaps C-q) would be other typical options, but especially ALT+F4 is annoying to type. Besides, the whole point of having a standard is that users only have to learn it once.


Would there be a need to standardize L2,L3 and R2,R3 mappings? I haven't really needed them myself yet, but it might be convenient to have a couple of additional action buttons available (perhaps optimized to prevent keyboard matrix conflicts).

 

[Zuk]

I think if more devs than not try to adhere to a standard, the rest will more or less fall in-line because that is what the users will want and expect out of the software.


I don't believe there is anything wrong with saying, "Hey, this is the button layout we WOULD LIKE you to use." I also believe that buttons should have the ability to be re-mapped if the user doesn't like the default.


One of the big annoyances I found with the Wiz was that every piece of software had a different button layout. The PND system relieved a lot of the software install issues found in other open-source handhelds. This is just one more area that I feel could be made a little more user-friendly. The argument could be made that this is a geek device and learning is required and yada yada. It's my opinion that the more user-friendly the device is, the more it will sell, and we will get more devs to support it.


I'm not looking for an Apple device like lock-down by any means. The beauty of open-source is that you can do what you want. On that same note, open-source relies on standards for interoperability for a reason.

 

[diligentcircle]

Perhaps I've missed something, but what about the case of emulators that actually use the Select button as a button of the emulated console?

I don't see a proposal for emulators to map Select like that. That's what Space is for. The suggested Select mapping is more for games.

 

[Caine]

I don't see a proposal for emulators to map Select like that. That's what Space is for. The suggested Select mapping is more for games.

No, foxblock suggested that select should close the application. That would conflict with using select as e.g. the NES select button.

 

[WizardStan]

There should be some consistency, whether it is game or emulator. ie, Pandora menu is always an overreaching menu button, pressing it brings up a menu of options, new game, quit, etc... while perhaps select can be used for in game menus such as magic, equipment, status, etc... Perhaps there is cause for the two to be the same from the developers perspective but those will be case by case: in the general case, whether it's a game or an emulator or whatever you should be able to expect a single key to act as some kind of main menu key to let you save/load/quit/whatever. This key is usually the escape key on desktops, but I think could be done with the Pandora key instead.


Escape key can then be reserved for some kind of hard quit.

 

[foxblock]

^ Except the pandora button does stuff in the underlying interface in both XFCE (opens menu [albeit in background], or quits applications when held) and MiniMenu (quits active application), so these would need to be changed first. I think it would make sense to make it the default "meta-menu" key (since nothing in ported etc stuff maps to it by default), but in that case we'd need to define its meaning a bit more strictly to avoid clashes. Perhaps we could have a dedicated combo for hard killing stuff, like L+R+Pandora (or something)? This would leave the pandora button free for application uses.


I see the select button as "quit dialog" or "in-game menu" button instead of direct quit button.


Personally, I support this control scheme. I just changed the buttons in my beefed-up follower for MilkyTest Panorama UI called "Consolidation" to fit this.

Exactly, I would prefer the Pandora key over the Select key any time. The select key does not even make that much sense, but it's located in the centre and it usually is not used for anything else (except in emulators, but I will get to that), so that's why I chose it over other keys.


The only major problem with that is as you say the hard-coded function of the Pandora key in both XFCE and Minimenu, which probably cannot overriden with ease. If we can get to a consensus to change that to something else (like a combination with another key - I personally dislike L+R+Pandora though, that's much too complicated), then it would go right into the "standard".


ESC again is also preferred over Select as it's much more obvious and intuitive, but has the problem of being slightly "hidden".


You are correct in the assumption that Select should not be "insta quit" (like ESC), but rather open a game-menu or quit dialogue (putting insta-quit on a non-obvious button, like... say F10 is just cruel - yes Valve I am looking at you!) - I will edit the description to make that clearer.

Perhaps I've missed something, but what about the case of emulators that actually use the Select button as a button of the emulated console?

I don't see a proposal for emulators to map Select like that. That's what Space is for. The suggested Select mapping is more for games.

Yeah, kind of, Select should be seen as an alternative to ESC, ESC should always be implemented for "exit (prompt)" and Select can be if it seems appropriate and the key is not occupied otherwise - then Select should be a global game-menu (not emulator overlay menu - that's Space), to provide options to exit the game, send it into some kind of standby mode, etc. (think of the later GBA and DS games which usually have this kind of menu attached to either L or Select).


As I said before I am not too happy with Select either, but it seems like a sensible solution for most cases for the reasons given - as long as the Pandora key is not available.

There should be some consistency, whether it is game or emulator. ie, Pandora menu is always an overreaching menu button, pressing it brings up a menu of options, new game, quit, etc... while perhaps select can be used for in game menus such as magic, equipment, status, etc... Perhaps there is cause for the two to be the same from the developers perspective but those will be case by case: in the general case, whether it's a game or an emulator or whatever you should be able to expect a single key to act as some kind of main menu key to let you save/load/quit/whatever. This key is usually the escape key on desktops, but I think could be done with the Pandora key instead.


Escape key can then be reserved for some kind of hard quit.

I completely agree, but as long as the Pandora key is not guaranteed to work in all cases I will stick with the split of Select and Space (for emulators, which btw is already used in most of them).


I know that saying "use where appropriate" is not ideal for a standard at all as well as splitting games/launchers and emulators, but so far I don't see a better way as forcing the select key is impossible and only relying on ESC seems not great for new users without introduction.

 

[PokeParadox]

^ Except the pandora button does stuff in the underlying interface in both XFCE (opens menu [albeit in background], or quits applications when held) and MiniMenu (quits active application), so these would need to be changed first. I think it would make sense to make it the default "meta-menu" key (since nothing in ported etc stuff maps to it by default), but in that case we'd need to define its meaning a bit more strictly to avoid clashes. Perhaps we could have a dedicated combo for hard killing stuff, like L+R+Pandora (or something)? This would leave the pandora button free for application uses.


I see the select button as "quit dialog" or "in-game menu" button instead of direct quit button.


Personally, I support this control scheme. I just changed the buttons in my beefed-up follower for MilkyTest Panorama UI called "Consolidation" to fit this.

Exactly, I would prefer the Pandora key over the Select key any time. The select key does not even make that much sense, but it's located in the centre and it usually is not used for anything else (except in emulators, but I will get to that), so that's why I chose it over other keys.


The only major problem with that is as you say the hard-coded function of the Pandora key in both XFCE and Minimenu, which probably cannot overriden with ease. If we can get to a consensus to change that to something else (like a combination with another key - I personally dislike L+R+Pandora though, that's much too complicated), then it would go right into the "standard".


ESC again is also preferred over Select as it's much more obvious and intuitive, but has the problem of being slightly "hidden".


You are correct in the assumption that Select should not be "insta quit" (like ESC), but rather open a game-menu or quit dialogue (putting insta-quit on a non-obvious button, like... say F10 is just cruel - yes Valve I am looking at you!) - I will edit the description to make that clearer.

Perhaps I've missed something, but what about the case of emulators that actually use the Select button as a button of the emulated console?

I don't see a proposal for emulators to map Select like that. That's what Space is for. The suggested Select mapping is more for games.

Yeah, kind of, Select should be seen as an alternative to ESC, ESC should always be implemented for "exit (prompt)" and Select can be if it seems appropriate and the key is not occupied otherwise - then Select should be a global game-menu (not emulator overlay menu - that's Space), to provide options to exit the game, send it into some kind of standby mode, etc. (think of the later GBA and DS games which usually have this kind of menu attached to either L or Select).


As I said before I am not too happy with Select either, but it seems like a sensible solution for most cases for the reasons given - as long as the Pandora key is not available.

There should be some consistency, whether it is game or emulator. ie, Pandora menu is always an overreaching menu button, pressing it brings up a menu of options, new game, quit, etc... while perhaps select can be used for in game menus such as magic, equipment, status, etc... Perhaps there is cause for the two to be the same from the developers perspective but those will be case by case: in the general case, whether it's a game or an emulator or whatever you should be able to expect a single key to act as some kind of main menu key to let you save/load/quit/whatever. This key is usually the escape key on desktops, but I think could be done with the Pandora key instead.


Escape key can then be reserved for some kind of hard quit.

I completely agree, but as long as the Pandora key is not guaranteed to work in all cases I will stick with the split of Select and Space (for emulators, which btw is already used in most of them).


I know that saying "use where appropriate" is not ideal for a standard at all as well as splitting games/launchers and emulators, but so far I don't see a better way as forcing the select key is impossible and only relying on ESC seems not great for new users without introduction.

Well there we are then... we just need to propose refinement of what the Pandora button actually does...

 

[chosen]

In XFCE there could be a key shortcut to minimize a fullscreen app such as game or emu (Pandora-D?) which can then be returned to. Also a system shortcut to kill the focused app would be useful if it crashes, instead of reseting the whole machine. I think L+R was suggested for killing.


It would be nice if pressing B game button on XFCE menus activated the item. The end key is not used here, so there is no clash.


Regarding q or Esc to quit. Q to quit is terrible, when playing Streetfighter in Snes9x4p doing a right facing dragon punch I'm about guaranteed to hit q and quit the emulator, so I have to redefine the XFCE keys so I can play. So I do insist that Esc to quit is the way to go.

 

[DaMummy]

one of the best things about pandora is that there is no background overhead as you propose, so minimizing many of the fullscreen apps is not a good idea, as that would equal to desktop background using up memory at all times

 

[Caine]

It would be nice if pressing B game button on XFCE menus activated the item. The end key is not used here, so there is no clash.

That's not true. Home/end jump to the beginning/end in the XFCE start menu.


[edit]


An argument to not change this behaviour is that by default A/B are mapped to home/end in XFCE. Even if you override this behaviour in the start-menu, you would not automatically override it in other menus or similar widgets. So essentially, you are creating a context sensitive keyboard mapping. That is a really bad idea.


[/edit]