[garbear]

There are many ways to jiggle around the controller UI here's one from a controller-centric point of view (I have another one nearly ready for a Core point of view).
It's only a REALLY REALLY quick sketch of how to put all the info in one panel.

Nice image! It can be difficult to visualize what large amounts of text are describing, but images are quick and efficient. Thanks.

First, a fundamental change I would make is to change "cores" to "platforms". The vision of zero-configuration emulation means that RetroPlayer decides the appropriate emulator based on the platforms listed in core's addon.xml, among other things. So the user would configure the controller loadout for NES, and RetroPlayer would present all NES emulators with the same loadout.

With this change, in order for us to create your idea we'll need a taxonomy of game platforms. This means gathering some platform lists from game info providers (like http://thegamesdb.net/platforms/ ) and creating a superset of platforms, then grouping these into platform families that support similar controllers. That way, the user can configure GBA once, and all cores that support Game Boy, Game Boy Color and GBA are automatically configured.

Is this something you could help create? It wouldn't require any coding, just some research. In addition to your manager, it'll be used for the game library, so this would be really beneficial to the RetroPlayer project.

Basically when the controllers are plugged in they appear at the top

This presents two difficulties.

First, we assume an infinite number of proprietary and DIY controllers, so it's not possible to have an image for every controller. Maybe we can show the image of the peripheral add-on presenting the controller?

Second, some controllers use keyboard drivers. There's no way to detect these, so we have to assume a large, unknown number of connected keyboard-based controllers at any time. How can we modify your idea to include this assumption?

The check at the front would indicate that this particular controller has been mapped for that particular emulator core.

My vision is the ultimate zero-configuration bliss. Necessarily, we'll need to generalize to unseen data. More powerful generalization requires increasing complexity. Increasing complexity means increasing maintenance costs and reduced scalability. These are my two greatest coding offenses, because maintenance cost affects other people, and scalability affects future performance.

Therefore, generalization in Kodi is unacceptable. To avoid this, I've added the assumption of an "oracle" that always returns the most likely configuration. According to this assumption, all controllers are always mapped, so we can't indicate that a particular controller is unmapped. How should we handle this?

• Remove this indicator
  
• Drop this assumption, and therefore zero-configuration
  
• Make the oracle also return an "accuracy" (this is difficult). That way, we can still show this indicator when accuracy == 0
  

It's really rough but this could work if we expand on it.

As soon as I get more free minutes I will finish up the other idea.

Any feedback is welcome!

I think this is a great start. As you can see, we have a lot of difficult challenges to overcome. I'd like to hear your thoughts on the above, and if you make an image for your Core idea post that one too!