flipBX - Gaming buttons (non-)standardization on Pyra

[bzar]

Edit: Also, won't XDG_CONFIG_HOME be ~/.config by default?  It might be appreciated by some if config settings could be stored on SD cards by default.  I guess I could always set XDG_CONFIG_HOME in my .bashrc (or one of the other boot/logon files) but it would be quite smart if it could do this automatically, perhaps with the automounter setting XDG_CONFIG_HOME when it mounts cards.

Yes, it would be ~/.config by default. The rationale is that these aren't settings for any specific application, and as such should not be stored with the application so they're available no matter what remomvable media is inserted. These would be preferences of a specific user for a specific device. Any application-specific settings should still reside on the SD card as per how DBP works.

 

[sebt3]

notice that the current pnd_run.sh set  XDG_CONFIG_HOME, XDG_DATA_HOME and XDG_CACHE_HOME to the appdata directory

I would expect the same behaviour on the pyra...

 

[ptitSeb]

notice that the current pnd_run.sh set  XDG_CONFIG_HOME, XDG_DATA_HOME and XDG_CACHE_HOME to the appdata directory

I would expect the same behaviour on the pyra...

But there should be a REAL_HOME with the real home in that case, IIRC?

 

[levi]

Hmm, yes, these settings should probably reside on NAND/eMMC, just like wifi settings, TV-out settings and all those other system settings do on Pandora.

It would make sense for the dpg/pnd system to retain setting XDG_CONFIG_HOME to the appdata folder, to make porting easier.  Perhaps set a new environment variable to point at the configuration, if a config file turns out to be the best way to do it (there'll always need to be a config file, but whether it's read by the system and turned into env var settings, or left for the application to pick up, that's the distinction).

 

[Grench]

I suspect that this is a case of fixing something that is inconvenient but not actually 'broke'.

Just as every game console can have a different pattern to the button usage, every emulator will want to have it's button usage for selections mimic those of the console it's driven by.  That is not necessarily a bad thing.

For Pyra specific applications, we have a whole freekin' keyboard with REAL enter, backspace and arrow keys.  Why the heck are you guys assigning X and B to ANYTHING in a non-emulator based application?  On a non-game Pyra application those keys are Page Down and End, not X and B.  Inside a game/emulator as action buttons, calling them X and B makes sense.  In the PND Manager, we should be using the Enter key for selection and and HOME or Page Up for back.

Computer applications - including the software 'store' - SHOULD behave as computer applications and not as a game console controller.

 

[PokeParadox]

I suspect that this is a case of fixing something that is inconvenient but not actually 'broke'.

Just as every game console can have a different pattern to the button usage, every emulator will want to have it's button usage for selections mimic those of the console it's driven by.  That is not necessarily a bad thing.

For Pyra specific applications, we have a whole freekin' keyboard with REAL enter, backspace and arrow keys.  Why the heck are you guys assigning X and B to ANYTHING in a non-emulator based application?  On a non-game Pyra application those keys are Page Down and End, not X and B.  Inside a game/emulator as action buttons, calling them X and B makes sense.  In the PND Manager, we should be using the Enter key for selection and and HOME or Page Up for back.

Computer applications - including the software 'store' - SHOULD behave as computer applications and not as a game console controller.

I completely disagree. The PNDManager should use the gaming controls AND some sensible keyboard buttons. If an application can be simplified to using the Dpad and an Accept button and a Cancel button then it makes sense to do so on a games console. If the application is a complicated desktop application that cannot be simplified to gaming buttons then it makes sense to just leave as keyboard controlled.

 

[foxblock]

I like this idea.

I think we definitely need a standard regarding buttons for menu interaction. The Pandora as an open console and ecosystem naturally does not support one mandatory way of doing things, instead promotes choice and customisation. I really liked the idea of giving the user full control over which button he wants as "accept", as "cancel", etc, however on second thought (as explained in this thread) this is not a good idea and just leads to more problems.

So I think this simplified approach could work for both sides.

It has to be available (in the OS) from the very beginning though! Maybe even get some major porters to support and use it right away, to give it some traction.

Further: I think it makes sense to have some documentation of "de-facto standards" available for developers at launch, which also includes recommendations for other buttons (like some sort of Pyra-Button-sequence to instantly exit a program, ESC as default exit button, a home button, button for emulator menu, etc. - whatever makes sense or is used in many applications). This might be a whole different topic though.

 

[Grench]

Menu selection in an application to download and update applications is a computer application/use.  It is not a gaming use in itself.  Forcing game controls for the primary application install engine is very short sighted.

In non game applications, the X and B buttons should be page down and end.

 

[ptitSeb]

My point of view here is :

a "flipBX" function, to invert X and B buttons in as many game as possible is doable on my side. I most of the time use X as primary and B as secondary, so inverting them makes sense, even when more than 2 buttons are used (because tertiary function is most of the time use seldomly). Anything more complicate will probably just fail.

Having a flag, either as an environment variable, or as file in /usr/pandora or someplace else is fine for me.

Now, if you want that to happens on the Pandora (that would be a good exercise before the Pyra), go ahead, and someone implement the mecanism to change / set that flag.

Once it's done, I'll update my ports with it.

 

[bzar]

Menu selection in an application to download and update applications is a computer application/use.  It is not a gaming use in itself.  Forcing game controls for the primary application install engine is very short sighted.

In non game applications, the X and B buttons should be page down and end.

The most convenient scheme should be used. Restricting the buttons to their default bindings does not sound like a good idea. How would you keymap PNDManager while only using the keyboard bindings for the game buttons? I'm fairly certain you'll end up with a less convenient user experience. Keep in mind that most of the keyboard needs to also do text input. Put every common action behind a modifier? Use a cursor to pick buttons? Those are both way less convenient.

 

[Haraldur]

What is wrong with just ignoring the gaming buttons as gaming buttons, considering X and B only as Page_Down and End? It is a trait of applications on "real" computers that keys may be assigned (indeed, it may be argued that all such applications "should" allow key reassignment). I can quite easily tell eDuke32 on the Pandora, the Duke Nukem 3D source port, to take End as the Fire command and Page_Down as the Mighty Foot command -- or, as I actually have done, take Page_Up and Page_Down as look up and look down, with Home and End as turn left and turn right, with Ctrl (right shoulder) as Fire and Shift (left shoulder) as Mighty Foot. By now, computer users should be accustomed to some applications, or classes of applications, using keys in "non-standard" ways -- WASD, anyone?

Besides, presumably no one objects to using the DPAD simply as the arrow keys? Besides, the face buttons are already labelled as normal keys -- leave them as they are.

 

[bzar]

Haraldur: I'm not sure who your post was replying to, but I have no problem with the game buttons producing keyboard key codes. Only that their function should not be dictated by them. If there's a list in an application X button should not be restricted to only scrolling it down by a page. There may be a better use for such a high value button usability-wise than scrolling down a list.

 

[Haraldur]

Haraldur: I'm not sure who your post was replying to, but I have no problem with the game buttons producing keyboard key codes. Only that their function should not be dictated by them. If there's a list in an application X button should not be restricted to only scrolling it down by a page. There may be a better use for such a high value button usability-wise than scrolling down a list.

My point is that in many applications, PC games especially, one can reassign Page_Down to do pretty much anything. Whatever the application does with the X button will be application-defined anyway, so why not have it as a reassignment of Page_Down? This is quite common -- most users should already be familiar with the concept -- and it preserves the meaning of the Page_Down label on the X button. As on a PC. From my point of view, the gamepad is just part of the keyboard, with some of the keys in unusual positions, with specific purposes in mind. I do not press X, I press the Page_Down key, which is interpreted by the application in any way it chooses. It is just a key-code. I am uncomfortable with the idea of there being a common practice of treating the X button as anything other than a keyboard key that produces the Page_Down keycode, and I do not see the point.

 

[bzar]

Haraldur: I'm not sure who your post was replying to, but I have no problem with the game buttons producing keyboard key codes. Only that their function should not be dictated by them. If there's a list in an application X button should not be restricted to only scrolling it down by a page. There may be a better use for such a high value button usability-wise than scrolling down a list.

My point is that in many applications, PC games especially, one can reassign Page_Down to do pretty much anything. Whatever the application does with the X button will be application-defined anyway, so why not have it as a reassignment of Page_Down? This is quite common -- most users should already be familiar with the concept -- and it preserves the meaning of the Page_Down label on the X button. As on a PC. From my point of view, the gamepad is just part of the keyboard, with some of the keys in unusual positions, with specific purposes in mind. I do not press X, I press the Page_Down key, which is interpreted by the application in any way it chooses. It is just a key-code. I am uncomfortable with the idea of there being a common practice of treating the X button as anything other than a keyboard key that produces the Page_Down keycode, and I do not see the point.

Yes, I have no issue with that. I have an issue with what Grench proposed earlier, which was that the buttons should stick to the common function of their key code in all contexts with an exception for games. For example only moving forward in menus with Enter key instead of X or B buttons.

 

[Grench]

Menu selection in an application to download and update applications is a computer application/use.  It is not a gaming use in itself.  Forcing game controls for the primary application install engine is very short sighted.

In non game applications, the X and B buttons should be page down and end.

The most convenient scheme should be used. Restricting the buttons to their default bindings does not sound like a good idea. How would you keymap PNDManager while only using the keyboard bindings for the game buttons? I'm fairly certain you'll end up with a less convenient user experience. Keep in mind that most of the keyboard needs to also do text input. Put every common action behind a modifier? Use a cursor to pick buttons? Those are both way less convenient.

I would use page down to scroll the listing of applications down 1 page rather than restricting to single down actions.

Enter to select.  Escape to back out.

It is an application download listing for a computer.  It has always bugged me that it looks and acts like an emulator's rom selection menu.

 

[Christoph.Krn]

To answer some of the questions, flipBX "only" covers a significant share of applications. It's just one puzzle piece in the buttons story, intended for when there are no specific contradicting button usage intentions for a software.

The problems that flipBX is supposed to mitigate ARE real. On the Pandora, like on other open handhelds, there simply aren't many commonly-agreed-upon, wide-spread button conventions that any user could rely on. There have been numerous attempts at standardization of button mappings, on numerous open handhelds before the Pyra, /because/ people have been encountering these problems. (These standardization attempts have failed.)

Button mappings can very well make sense in an application individually. It's the switching between applications, application incompatibility to a given user's learned finger muscle memory, where the problematic disharmony occurs. Individually, each application still 'works', there are no compiler errors, the button mapping 'makes sense'. Why would one want to bother with system-wide button guidelines which don't fit the application as well as the customized ones do? Guidelines would maybe work if, say, every application for open handhelds ever was a Jump 'n' Run -- or in other "limited" situations, such as when it comes to unifying Confirm/Return buttons across applications' menus.

Even if there were mandatory, enforced button guidelines, or even just enforced key reassignment menus in all applications, they'd be sub-par solutions. Traditionally, there is a huge diversity in terms of what types of software can be found on open handhelds. If a software author creates a specific, 'non-standard' button mapping for an application, it's usually a good thing.

For software where flipBX doesn't make sense, and for developers who have different views, I'm offering other puzzle pieces in the form of guihints and (the much more recent) "Escape path key" and "Menu buttons" metadata in DBP.

 It [PNDManager's listing of applications, remark Christoph.Krn] is an application download listing for a computer.  It has always bugged me that it looks and acts like an emulator's rom selection menu.

Like the Pandora is not a regular gaming console, it's not a regular computer either. We will have to construct our own way here, possibly with an entire spectrum of systems and solutions, to accommodate for different cases. I think that flipBX should be one of these systems, because if you look at how all the software on the Pandora uses the buttons, you can find either variety of button usage ("gaming system"/"computer"), and arguments about whether the "right" variety is being used could be had in many cases, but in any case, on an open handheld it won't be possible -- or, in fact, desirable -- to enforce one of these varieties over the other for a given software.

This clash between these two worlds is still an unsolved problem though. I've been thinking about this before, and I hope that it can be solved with new ideas and projects, but right now, I don't really have any good ideas. Maybe something that's based on FunKeyMonkey will be helpful here. Also, talking with software authors.

(I'm aware that there are other interesting questions about this matter that don't have anything to do with buttons, but I don't want to extend this discussion here too much. Oh, and by the way, personally I'd be very interested in hearing a more detailed breakdown of your specific view of, and opinion on, PNDManager, though not here in this thread of course.)

[...]

a "flipBX" function, to invert X and B buttons in as many game as possible is doable on my side. I most of the time use X as primary and B as secondary, so inverting them makes sense, even when more than 2 buttons are used (because tertiary function is most of the time use seldomly). Anything more complicate will probably just fail.

...the name "flipBX" should probably be changed, so that it's clear just from the name that this setting is supposed to /exclusively/ apply to menus or other aspects of applications where (B) and (X) are like "Confirm"/"Continue" and "Cancel"/"Back".

Any suggestions for a better name? How about "MenuControl" or "flipBXMenus"?

 

[Grench]

B and X are only used for enter and escape type actions on game consoles because they have limited controlers.  It makes sense for emulators to use those as the consoles they reflect.  

However, it's rather nuts to even consider those restrictive conventions in any software designed for a full keyboard device - let alone a  primary software distribution platform.

You guys are all arguing over X vs B.  They're both wrong.  It's a handheld computer with a full keyboard that can run emulators.  Why should we be pretending that it doesn't have a keyboard?  Unless you're in a game, those buttons are page down and end.

 

[bzar]

Any suggestions for a better name? How about "MenuControl" or "flipBXMenus"?

PrimaryMenuButton or MenuOKButton with possible values "B" and "X" seem self-explanatory to me. It has the added benefit of being somewhat clear on which actually is the primary button. FlipBX naming in PNDManager was short-sighted . I assume the default value (when no value is present) is "let application decide"?

 

[bzar]

I would use page down to scroll the listing of applications down 1 page rather than restricting to single down actions.

Enter to select.  Escape to back out.

It is an application download listing for a computer.  It has always bugged me that it looks and acts like an emulator's rom selection menu.

Please continue. You have defined alternatives for two of the buttons. Six to go (A, Y, start, select, L, R).

 

[Ziz]

It's not like, we have not discussed this before... In this thread were some neat ideas!