Launcher 1.25 issue with "Buttons Layout"

As you may know, in the Launcher’s Menu “Settings -> Buttons Layout” you can choose between 2 modes: “SNES Compatible” and “XBOX Compatible”.
Buttons Layout
The Launcher (till) ver. 1.24 respects your choice, and (i guess) assumes, that you also switch the physical buttons order to the desired scheme accordingly.

Personally, i prefer the “SNES Compatible” mode with accordingly placed physical buttons (when labels on physical buttons corresponds to labels on “SNES Compatible” image).

But Launcher ver. 1.25 (with OS 0.4) confuse, since the behavior has been changed, and it looks like it no more assumes that user also switch physical buttons to the desired scheme, and always labels for “XBOX Compatible” physical button order.

for example, if you choose “SNES Compatible” Buttons Layout, and place the physical buttons accordingly, you will be confused,
because in the Launcher you see that “A” is for “Back”, but pressing the physical button labeled “A” do the action labeled for “B” button in the Launcher - “Enter”, and vice versa.

So, could someone from DEVs of the Launcher clarify,
if it was done on purpose and will NOT be changed,
or it’s a bug that will be fixed with next update of the Launcher?

1 Like

oh, i see that @cecilectomy already raised this issue on github


Yeah, but unfortunately from what I understand after the discussion in the comments of the pull request, is that they decided to do it this way. It’s a shame because it makes no sense and hurts the users who actually want to use the layout feature correctly as a physical layout change. I really don’t want to, but I might have to switch to XBOX layout just so the buttons match the on screen prompts correctly :frowning_face:

1 Like

Easy way to fix it is to modify footbar.png in /home/cpi/launcher/skin/default/

1 Like


just rename it to footbar.png, replace it and switch physically buttons.

While a simple temporary solution it is not a permanent fix and would get overwritten on launcher update. You could make it more permanent with a custom skin, but it still isn’t an ideal fix. It should just be fixed in the launcher, not left the way they changed it to for nonsensical reasons. Hopefully whoever decided it needed to be changed see’s it was a terrible decision and decides to let it be changed back. There have been several people bring this up already, and many people agree the change is just wrong.

1 Like

The only thing I’m guessing they did this for was for some external applications, such as the PICO-8 installer that have dialogue boxes asking definitive yes/no questions, using A/B as input options. That and DinguxCommander simply not respecting what you have set your accept/back key to be.
There’s probably other things deeper that will continue to use the physical hardware A/B buttons set in the XBOX format, that the person in charge of the recent change decided that it would be “safer” to assume people have their hardware setup this way.

I would be curious to see a poll asking what gameshell owners have their hardware physically set up as. Given the nature of what is emulated, I’m willing to bet that the majority would have the hardware (and thus software) set to the SNES orientation.

Hopefully your pull request gets followed up on, @Cecilectomy.

I’m not sure things like DinguxCommander can really ever be fixed, unless the maintainers fix them or someone forks and fixes. The closest alternative would be to remap keys on launch as a lot of other applications have to do. (e.g. Alex4 They have their own key bindings that are not configurable, but keys can be mapped to other keys to get around this. Their layout change doesn’t solve this in the slightest, it just shifts the problem elsewhere at best.

For things like the PICO-8 installer which are part of the GS launcher themselves (I assume that is what you are talking about, it isn’t external as far as I am aware, you can see the code here), the input options were already correct for both SNES and XBOX physical key layouts BEFORE they made this change (this all happens in the footer logic for button input options). With the change, they have only made the physical SNES layout incorrect.

I hope so too.

1 Like

I understand that this solution is temporary, but either way you need to change something after update. For example, my retroarch shortcut is the second after settings. So…whatever…

I think it’s more how they handle the footer.png file, and the placement thereof of the icons. If you’re using the stock skin, and just do a copy paste, then great! Your file you uploaded is perfect :slight_smile: Thanks for your solution.

I actually did exactly the same thing myself the day the update hit, only having it as an alternative skin, as mentioned above. I also used to change the order of icons, like you did with retro arch. In the end I decided it was way too much trouble to keep up with, relative to launcher updates.

It just “broke” too much of the folder hierarchy in place. At least with a skin, it only applies variables if they exist. Plus having the “default” layout generally means community shared skins work without much fuss.

It’s other factors that make the current interface unacceptable, like if people have made their own skins to distribute. It would be an extra (albeit) small step to have two version; one for snes layout hardware, and another for Xbox.
Logically, if you want to have the layout of your preferred console, given the modular nature of the Gameshell, you would assemble it in the same way.

Prior to 0.4, it would just do it “right” without needing to upload an alternative footer.

@Cecilectomy covered this already extensively in github, so I won’t tread repeat too much. :slight_smile:

I have my own solution - I edited the file here described in his commit.
It’s /home/cpi/launcher/ After editing it with the proper button layout I ran ‘python -m py_compile’ from the console.
Works fine, just can’t update my launcher now.

1 Like

I’ll have to look into it tomorrow, but having the button layout set to Xbox mode, and reconfiguring the keyboard as per this tutorial by @Petrakis should result in everything being corrected, including being able to update the launcher without losing your layout.
Not just the references to keys in the launcher, but also externally maintained packages (eg, dinguxcommander)