This PR completely separates all mrext/MiSTer related code and the TapTo core code. Code calling mrext now only exists in its specific cmd and platform modules.
It does this by introducing the "Platform" interface, which is handed to the daemon and API services at compile time. This interface contains all platform-specific functions and configuration options. If we want to port TapTo to a new system, create a new platform module and implement the interface, it should work!
I have also partially copied the systems list from mrext. The list in TapTo only contains the system IDs, folder names and file extensions. Just enough to perform some indexing. I'm planning later to introduce the GameID project (https://github.com/niemasd/GameID/tree/main) by @niemasd to have game detection in a platform agnostic way. So there is a separation of duties, TapTo core identifies and indexes the games, the launching of games is handled by the individual platform module (in mister's case we'll continue using mrext) (that's my implementation idea @asturur)
I'm not totally happy with this yet, but I just want to get it over the line for now and in a state where it's totally separate and (seems to) run without change.
Some notes I had:
Probably time to redo the build system. Mage feels very overengineered now. I'd like to use something simpler. I have been using go-task lately and enjoying it
I'm not sure if the "software tracking" in the reader loop is still working correctly. I had to make it so the menu core is never reported and return an empty string
Now that system names are removed from the systems list, it's broken the systems API endpoint. I added a workaround for now that reports the name as the ID
I noticed that the line between "launcher", "software" and "system" is very blurred. I think these all refer to the same concept after going through all this
What are your thoughts of the interface? It's a bit all over the place right now. This is the time to make some decisions about how it should work going forward so I'm keen to hear what you think
This PR completely separates all mrext/MiSTer related code and the TapTo core code. Code calling mrext now only exists in its specific cmd and platform modules.
It does this by introducing the "Platform" interface, which is handed to the daemon and API services at compile time. This interface contains all platform-specific functions and configuration options. If we want to port TapTo to a new system, create a new platform module and implement the interface, it should work!
I have also partially copied the systems list from mrext. The list in TapTo only contains the system IDs, folder names and file extensions. Just enough to perform some indexing. I'm planning later to introduce the GameID project (https://github.com/niemasd/GameID/tree/main) by @niemasd to have game detection in a platform agnostic way. So there is a separation of duties, TapTo core identifies and indexes the games, the launching of games is handled by the individual platform module (in mister's case we'll continue using mrext) (that's my implementation idea @asturur)
I'm not totally happy with this yet, but I just want to get it over the line for now and in a state where it's totally separate and (seems to) run without change.
Some notes I had:
@asturur and @sigboe can I please get you to take a look through this list: https://github.com/wizzomafizzo/tapto/compare/wizzo/split-indexing?expand=1#diff-1882c3a96e0a351a1471f851024987ed299b44977c119020244e91c54dca3a10
What are your thoughts of the interface? It's a bit all over the place right now. This is the time to make some decisions about how it should work going forward so I'm keen to hear what you think