[WIP] Recalbox Manager

[Substring]

@DjLeChuck haaaannn t'as pas lu

## EmulationStation menu style 
# Values:
# default: default all options menu
# none: no menu except the game search menu
# bartop: less menu, only needed for bartops
system.es.menu=default

Tu vois la section Values: elle n'existe pas par défaut. C'est un commentaire qui sert à dire à un interpréteur comme t aversion du manager "system.es.menu prend 3 valuers possibles : default, none et bartop, avec les commentaires inhérents". Et il y a un double dièse sur un début de commentaire de variable.

L'idée était d'utiliser le recalboc.conf du share_init puisque c'est lui la référence (mis à jour, non touché par les utilisateurs), et mettre à jour en face le recalbox.conf du share

[DjLeChuck]

@subs Si j'ai lu (seulement le fichier, pas les explications en dessous :P) Mais actuellement ça y ressemble donc pardonne moi de ne pas avoir fait attention à la différence ^^ :

## EmulationStation menu style 
## default -> default all options menu
## none -> no menu except the game search menu
## bartop -> less menu, only needed for bartops
system.es.menu=default

Maintenant que j'ai lu les explications d'en-dessous et que tu me l'a expliqué également je vois de quoi tu parles.

Je ne suis pas encore au fait de comment fonctionnent les différente configs mais du coup là je comprends mieux l'utilisation que tu voudrais voir. En soit ça me va comme ça, puisque de toute façon ça concernera neolao et son API, pas mon manager

[Substring]

@DjLeChuck non neolao se contente d'appliquer des valeurs ou de les extraire. Ces comms ont été ajoutés pour une IHM explicitement, qui permettrait de paramétrer tout le recalbox.conf

[DjLeChuck]

@subs L'API de neolao prend la valeur que tu lui envoies en l'enregistre en l'encapsulant dans des double quotes d'où le bogue dont je parlais : https://github.com/recalbox/recalbox-api/blob/1.1.x/bundle-es6/utils/IniFile.js#L125-L131

Sinon, les commentaire sont très bien oui ça me permet de savoir quoi proposer à l'utilisateur comme options par rapport à ce qui est indiqué sans me poser de questions, donc c'est très bien !

[Substring]

@DjLeChuck justement, au boulot, faut que ta version du manager puisse tout faire sur le recalbox.conf. J'attends ta PR

[DjLeChuck]

@subs Haaa je comprends plus rien... XD Tu ne veux plus que j'utilise l'API et que je fasse directement des modifs dans le recalbox.conf de share_init ?

[Substring]

@DjLeChuck non pas du tout. Tu utilises l'API sans pb, mais ton interface tu la termines pour qu'elle puisse gérer tout recalbox Et surtout :

• le reboot/shutdown
• le script de support
• un bouton "kill running emulator" genre "panic mode" pour éviter que les gens rebootent leur recalbox et couinent qu'elle est cassée
• je ne sais pas quoi encore

NodeJS ou django, à ton aise

[DjLeChuck]

@subs Ha ! Oui ça c'est bon. Je gère déjà le reboot / shutdown (puisque l'API le propose).
Le script de support faudra que je vois comment ça marche.
Pour le kill running emulator et autres je verrais pour faire une PR sur l'API pour ajouter cette fonctionnalité d'abord. Sauf si on part du principe que mon manager s’intégrera dans recalbox directement ce qui me permettra de faire des appels systèmes tranquillement (ou alors qu'une des possibilités de l'API est d'exécuter une commande système et de renvoyer le résultat...)
Mais comme je suis en train de voir pour basculer sur du Node plutôt que du PHP je vais devoir reprendre ce que j'ai déjà...

[Substring]

@DjLeChuck si ton truc est abouti et viable, oui on peut l'intégrer. Le manager dans son état actuel risque fort de prendre la poussière ...

Pour le kill des emulateurs, on a déjà un embryon sur un autre topic en python, mais rien de difficile, si ce n'est que l'utilisation de python est pratique par rapport à configgen (qui a entre autre quasi tous les les binaires des émuls de listés)

[DjLeChuck]

@subs Ok donc raison de plus pour le passer en Node afin de pas s'embêter à avoir PHP encore en plus sur recalbox...

Si tu retrouves le topic je suis preneur dans ce cas, sinon je le chercherais dans tous les cas le moment venu !

[Substring]

@DjLeChuck regarde ces 2 liens :
https://forum.recalbox.com/topic/3504/emulator-exit-button-gpio/11
https://forum.recalbox.com/topic/3435/game-reset/10

le 1er est celui que tu cherches. Le 2e est juste un petit coup de génie sur comment faire le reset d'un jeu sans HK avec un buoton GPIO (mais la techinique uilisée derrière n'a pas besoin de GPIO)

[neolao]

Je me replonge dessus petit à petit chaque jour.

Le plus gros changement sera celui de subs. Une partie de l'API sera donc totalement dépendant de recalbox.conf

Le reste sera des alias ou des choses supplémentaires qui ne touchent pas à la config.

J'ai une réflexion sur les URLs des endpoints à choisir seulement.

[DjLeChuck]

@subs Merci pour les liens
@neolao Si jamais tu as besoin d'un coup de main ne serait-ce que pour la réflexion hésites pas à demander par MP par exemple.

[Substring]

@neolao comme je l'ai dit plus haut : ton api elle s'en fout du recalbox.conf, c'est l'IHM derrière qui doit gérer ca proprement. Enfin personnellement, je pense que ce n'est pas à tno API de vérifier si les valuers données sont bonnes ou non. Elles doivent t'êtres données au bon format, tu ne devrais pas avoir à te poser de questions sur leur validité

[DjLeChuck]

@subs Heuu là je suis pas d'accord... Certes de mon côté le manager doit envoyer une valeur correcte mais je ne suis qu'un client de l'API. Le côté serveur c'est justement l'API donc il FAUT une validation côté serveur ce n'est pas sécurisé sinon et n'importe qui peut envoyer ce qu'il veut comme donnée et réaliser des injections.

Après ça c'est dans la pratique habituelle des choses. Ici comme tu l'as déjà répété le système n'est pas ouvert etc. mais bon tu peux te faire pénétrer ton réseau et voilà...

[Substring]

@DjLeChuck mais c'est déjà le cas ! tu peux envoyer ce que tu veux je parie comme valeur à l'API

[neolao]

J'ai oublié si on peut pour tout type de propriété.

En tout cas, je confirme que c'est à l'API de gérer les bonnes valeurs.
Il pourra même servir les valeurs possibles, ce sont des ressources en GET finalement aussi.

[neolao]

Et potentiellement, comme le frontend a ses traductions pour les noms de propriétés, valeurs et descriptions, l'API peut exposer les traductions aussi.

Un manager web serait comme un frontend à recalbox.

Idéalement, le frontend en sortie vidéo devrait être découplé du backend via une API. Ce qui permettrait d'en changer.
Dans mes ambitions, je voulais allez loin et l'API est la première pierre.

[DjLeChuck]

@subs J'ai pas compris ta réponse ^^' Oui on peut envoyer ce qu'on veut à l'API sans qu'elle ne dise rien et ce n'est pas normal. Elle devrait contrôler les données reçues.

@neolao Pour les valeurs possibles elle pourrait oui, mais ce n'est pas une obligation car c'est à ça que sert une doc aussi, indiquer ce qui est possible de faire ou non, et on en est pas encore là De même pour les traductions elle pourraient être données dans l'API mais ce n'est pas non plus une obligation. L'API peut très bien rester "bas niveau" et ne donner que les valeurs bruts ce n'est pas déconnant.

[neolao]

Bien sûr, je parlais de ressources supplémentaires qu'elle pourrait fournir.

Imagine pour paramétrer la résolution de l'écran qu'une ressource te donne les valeurs possibles par rapport à un diagnostique.

Je vais peut-être faire une différence d'URI pour modifier la configuration et les autres actions. Par exemple, changer le volume, il y a une différence entre modifier la config et modifier le volume courant.
Actuellement, le endpoint est /audio/volume.

Je ferai peut-être un /config/audio.volume pour être dans le schéma /config/{property}.