Utiliser des KID comme noms de fichiers

Voilà on va commencer direct par un crochet du droit.

Utiliser des noms de fichiers selon le sens du vent ou des majuscules à la mode a de moins en moins de sens vu tout ce qui passe par l’application. Et ça rend plein de code extrèmement compliqué :

  • Ajout / suppression des karas : le nommage des fichiers dépend des tags, quand tu changes un tag tu fous le bordel dans le nom de fichier

Et y’a sûrement vingt mille autres endroits où j’ai pesté contre ça en codant des trucs.

Du coup je comprends bien qu’il y en a que ça va faire râler, surtout ceux qui éditent leurs fichiers à la main alors qu’ils ne devraient pas le faire vu que l’app peut tout gêrer désormais mais il faut aussi bien qu’ils se rendent compte qu’une vaste majorité des bugs sont liés à des noms de fichiers qui changent, des soucis de majuscules/minuscules sous Windows, et d’autres joyeusetés.

Maintenant, qu’est-ce qu’on peut faire pour palier à ça ? Réfléchissons en admettant qu’on utilise ce système :

  • Ecrire un fichier texte dans le dossier medias. Ce fichier aurait la liste des KIDs avec en face le nom du kara. Ca pourrait ^même être un CSV pour être triable dans un tableur si vous voulez.
  • Indiquer le KID du kara sur son Karadetail côté opérateur et côté systempanel quelque part afin que l’on sache rapidement quel est le KID à modifier à la mano si vraiment on doit le faire à la mano, par exemple pour réencoder.

J’aimerais bien que les principaux intéressés nous aident à connaître les cas qui les obligent à manipuler les fichiers de KM à la main, afin qu’on comprenne ce que ça pose comme soucis qu’il faudrait prendre en compte et comment on peut les résoudres.

Désavantages

Parce qu’une idée n’est jamais sans désavantages :

  • Si un jour on gère le multi-medias et multi-lyrics par kara, on est un peu niqué. Enfin il faudra probablement revoir un peu ça.

Pas forcément en fait. On a des champs “version” et “default” dans le json. Donc on peut dire si default à true alors que le kid sinon kid-version. voilà.

Oui on peut faire un truc comme ça en effet. Le souci c’est que ça attache encore un nom de version libre de saisie à l’utilisateur et le jour où je sais pas moi “Madoka Vers.” devient “Minako Vers.” bah euh… :slight_smile:

Ou alors faut donner des ID numériques à attacher derrière, qui serait le numéro de la version dans le tableau

Since this thought doesn’t let me sleep peacefully, here my thoughts on that:

I see why having the KID as filename would make it easier handling the files in the code. It’s good being already able to manage much of the base like the lyrics in KM itself, but I think there are still cases where the actual name in the filename is useful. It seems that this change would make the base itself much more depending of the KM App, making it less “open” / managable / modular on a file basis.

As someone who often works with the files itself, either for debugging, quickly finding the files for a new version, an edit or some other project, or for managing a local base, I think this would make some things more complicated for some people.

Although I prefer the current naming convention, maybe something in between, like adding the kid on the end of the filename - like the tags are - could make it better?

Merci pour ce commentaire @Themio :stuck_out_tongue:

L’argument “dépendent de KM App” est recevable et je le comprends, c’est vrai que c’est un point non négligeable à prendre en compte. Je n’y avais pas pensé.

Ajouter le KID (ou une partie) dans le nom du fichier ne changerait pas grand chose. L’avantage qu’ont les tags c’est qu’ils changent très rarement de nom, alors qu’un fichier kara.json change plus souvent, il suffit de l’éditer et qu’un tag qu’il utilise ait été modifié pour que son nom change de nouveau.

Bref, j’ai l’impression que ce problème est peut-être insoluble…