Sommaire
Trois mois plus tard
Peut-être vous rappelez vous de mon article sur la préservation du jeu vidéo qui a précédé la naissance du projet Badnik que je vous ai présenté fin juillet dernier.
Et bien le projet a avancé tant bien que mal cet été :
- il a été décidé que Badnik serait le nom du projet, mais ne sera pas celui des logiciels produits ;
- le frontend a eu droit à une icône plus personnalisée ;
- le backend a été porté vers Vala, mais dépend encore de GTK ;
- le frontend en GTK 3 et Python 3 a été amélioré, mais est destiné à disparaître (changement de langage ou réécriture) ;
- le build system n'est pas au mieux de sa forme (je ne parle malheureusement que le Makefile, si quelqu'un a des connaissance en Automake je suis preneur) ;
- la dépendance floue du frontend vers libgd distribué par GNOME Documents est toujours là, mais ce dernier étant destiné à disparaître ce n'est pas si dramatique ;
- le .vapi d'une des bibliothèques que j'utilise (libgda) est assez bancal, je ferais bien de la remplacer par sqlite3 directement ;
Si tout ça n'est pas forcément merveilleux, ce n'est rien à côté du problème auquel j'ai été confronté :
un des points forts de mon application, à savoir sa recherche et son affichage de métadonnées sur les jeux de votre bibliothèque, repose sur un système très bancal.
Le programme analyse des sites Web spécialisés, et s'il rendent parfois des résultats plutôt bons, ils étaient généralement trop lents mais surtout ne marchaient pas correctement pour tous les jeux : on peut ne pas trouver les données souhaitées alors que le site les contient ou, pire encore, avoir des données ne correspondant pas du tout au jeu ! De plus une connexion à internet est nécessaire et les recherches sont plutôt lentes.
Ce problème me semblant prioritaire, j'ai récemment réfléchit au sous projet GameData.
GameData
Si emmener mon programme vers les métadonnées ne marche pas, alors il me faut faire venir les métadonnées vers mon programme !
Il existe des tonnes de sites référençant des jeux vidéo mais pratiquement aucun n'est réellement exploitable, il me fallait donc une base de métadonnées de jeux facilement exploitables par un programme, et si elle pouvait être embarquée avec le logiciel ça ne serait que mieux !
Richard Hughes s'est heurté à un problème similaire avec son projet GNOME Software et y a répondu en créant AppData, une application XML dont les applications qui souhaitent apparaître dans GNOME Software doivent embarquer un fichier afin de rendre leurs données (nom, description, captures d'écran) accessibles aisément au programme.
L'idée est intéressante et j'ai décidé de m'en inspirer pour créer GameData, une application XML inspirée d'AppData mais spécialisée pour les jeux vidéo.
<?xml version="1.0" encoding="UTF-8"?>
<game>
<id>sonic-the-hedgehog</id>
<license>cc0</license>
<title>Sonic the Hedgehog</title>
<description>
<p>
In an attempt to steal the six Chaos Emeralds and harness their power,
Dr. Ivo Robotnik has trapped the animal inhabitants of South Island in
cybernetic shells and metal capsule prisons.
</p>
<p>
Control Sonic the Hedgehog to stop Robotnik's plans by freeing your
animal friends and collecting the Chaos Emeralds.
</p>
</description>
<release_date>
<day>27</day>
<month>06</month>
<year>1991</year>
</release_date>
<genres>
<genre>platform</genre>
</genres>
<screenshots>
<screenshot type="default">
http://info.sonicretro.org/images/6/6f/Sonic1_title.png
</screenshot>
<screenshot>
http://upload.wikimedia.org/wikipedia/en/d/d3/MD_Sonic_the_Hedgehog.png
</screenshot>
</screenshots>
<covers>
<cover type="default">
http://upload.wikimedia.org/wikipedia/en/b/ba/Sonic_the_Hedgehog_1_Genesis_box_art.jpg
</cover>
</covers>
<developers>
<developer url="http://www.sonicteam.com/">Sonic Team</developer>
</developers>
<modes>
<mode min_players="1" max_players="1">local</mode>
</modes>
<controllers>
<controller buttons="4">gamepad</controller>
</controllers>
</game>
<id />
J'ai commencé à définir GameData sur cette page Web et le format n'est pas encore fixé, si vous voyez le moindre manque ou problème dans la définition du format n'hésitez pas à me le signaler car je souhaite le peaufiner avant de "lancer la production" de ces fichiers.
Je suis également en train d'écrire une bibliothèque en Vala pour manipuler de tels fichiers.
Futur du projet
Même si le projet avance lentement (ma vie passe avant lui) il est loin d'être mort et je souhaite lui mettre un gros coup de polish et étendre ses horizons.
Pour ce faire, je souhaite :
- nettoyer le backend en Vala, retirer toute dépendance superflue comme GTK+, et ce afin de le rendre très portable tant entre langages (Vala est très bon là dessus grâce à GOI) qu'entre environnements ;
- faire un frontend pour GNOME propre, laisser la possibilité de créer d'autres frontends (en prenant Transmission pour modèle) ;
- afin de faire avancer le projet plus vite qu'entre mes seules mains et surtout parce que la création de milliers de GameData est trop pour un seul homme, j'espère monter une communauté (voire un site) autour du projet !
Si vous êtes intéresser à faire avancer le jeu vidéo sous Linux ou la préservation du jeu vidéo, et que vous souhaitez participer, n'hésitez surtout pas à me contacter (le projet étant encore jeune c'est le moment parfait pour ça) !
# XML, encore et toujours.... le mauvais choix pour la mauvaise utilisation.
Posté par freem . Évalué à 6.
Note préalable: je fais un sujet spécifiquement sur XML, parce que, voila, ça me gonfle de voir ce truc illisible utilisé pour tout et n'importe quoi.
Je peux savoir quelle est la raison d'utiliser XML pour l'exemple cité?
Ca n'a juste… aucun intérêt, si ne c'est de ne pas être maintenable facilement à la main. Je sais que certains sont de vrais fan de XML, mais voici à quoi ressemblerait le même contenu, pour un paquet Debian (qui est quelque chose de bien éprouvé pour ce type d'usage, donc. Et je reprend ici tout, alors que je n'aurai pas forcément utilisé les même clés. En plus, je n'ai pas mis de description courte, vu qu'elle n'existe pas dans le fichier XML…):
Le public avertis de ce site éclairé aura constaté quelques adaptations libres autours de certains aspects, tels que les modes et les contrôleurs.
En réalité, pour Debian on aurait utilisé les debtags pour nombre de ces données, comme le genre. D'ailleurs… ceci devrait t'intéresser.
Je ne sais pas si ce n'est que moi, mais en tout cas ça me semble déjà bien plus lisible (*), à la fois pour l'homme, mais aussi pour un programme ( pas besoin de vérifier la cohérence des balises, notamment ).
Il aurait aussi été possible d'utiliser JSON, un peu moins pire qu'XML pour l'usage et avec pleins de lib pour l'intégrer directement dans du code, ou bien YAML (clairement plus propre que les langages à balise que sont XML et JSON…).
Tous ces choix auraient été, il me semble moins ridicules que XML. Oui, je suis un XML hater, et fier de l'être, parce que personne n'a jamais pu me dire en quoi XML est supérieur à tous les autres formats sur tous les usages.
*: au sujet de la lisibilité, je pense que ce qui l' handicape le plus, c'est le fait que j'ai retranscrit comme une brute les informations provenant d'un XML, sans réfléchir. Et puis, les URL n'aident pas. Je n'ai pas non plus aéré le texte, alors que j'aurai pu, avec notamment des retours à la ligne lorsque le contenu d'une catégorie prends plusieurs lignes.
[^] # Re: XML, encore et toujours.... le mauvais choix pour la mauvaise utilisation.
Posté par Kekun (site web personnel, Mastodon) . Évalué à 5. Dernière modification le 11 novembre 2013 à 17:20.
Je ne suis pas spécifiquement pro XML mais c'est le format que je connais le moins mal, et celui utilisé par le format dont je me suis inspiré.
Avec les formats que tu as cités peut-on :
Je ne suis pas contre changer de format, mais comme je n'ai absolument rien contre XML (je pensais éventuellement créer une petite application spécialisée pour faciliter la création des GameData, donc la verbosité n'aurait pas tant été problématique).
[^] # Re: XML, encore et toujours.... le mauvais choix pour la mauvaise utilisation.
Posté par freem . Évalué à 1. Dernière modification le 11 novembre 2013 à 18:12.
Tu n'as qu'a copier/coller 100 fois ton texte dans le même fichier, et me dire que tu trouves ça lisible… en toute bonne foi, bien sûr.
Enfin, au niveau des formats que j'ai cités: JSON en est capable, celui de debian aussi ( même que c'est ce qui est fait dans "/var/lib/apt/lists/*". Je ne le savais pas, mais ta question m'a poussé à regardé comment c'était foutu…), et je ne doute pas que YAML le puisse aussi, je connais moins ce format (je me le garde juste en mémoire pour le jour ou j'en aurai peut-être besoin. Ceci dit, wikipedia montre très bien ce qu'on peut en faire).
Ce que tu dis me fais penser à l'héritage, en POO. C'est le truc que l'on apprend a arrêter d'utiliser à tout bout de champ (comme ce que je prône pour XML en fin de compte) au bout d'un moment, parce que ça pose plus de souci que ça n'en résout.
Debian résout ce problème de façon très simple: les debtags.
Un extrait d'un fichier de /var/lib/apt/lists fera un bon exemple, je pense:
Je ne sais pas pour toi, mais je trouve ça plutôt lisible. Peux-tu faire la même chose, en aussi lisible, avec un format plus riche?
[^] # Re: XML, encore et toujours.... le mauvais choix pour la mauvaise utilisation.
Posté par dave_null (site web personnel) . Évalué à 4. Dernière modification le 11 novembre 2013 à 17:26.
Je ne suis pas vraiment un fan du XML mais tout n'est pas noir avec XML. L'environnement est très fourni, il y a plein d'outils pour XML.
Tu peux valider ton document, avec des schémas DTD ou XSD, c'est indispensable pour un service par exemple.
Tu peux aussi faire des transformations XSLT, pour générer un document XML à partir d'un document XML avec des règles définies dans un document XML.
Et tu as plein d'outils qui font oublier que derrière tu as du XML.
Enfin bref, XML c'est un peu plus qu'un dictionnaire clef/valeurs.
[^] # Re: XML, encore et toujours.... le mauvais choix pour la mauvaise utilisation.
Posté par freem . Évalué à 5.
Exactement. Et c'est pour ça qu'il ne doit pas être utilisé quand tu n'as besoin que d'un tel dictionnaire.
[^] # Re: XML, encore et toujours.... le mauvais choix pour la mauvaise utilisation.
Posté par hervé Couvelard . Évalué à 3.
peut être parce que lorsque tu fabriques la DTD quivabien(c) tu peux fabriquer les fiches en étant certain que sa grammaire est correcte ?
Que les tags obligatoires y sont, que tous les tags existent… ce genre de chose, en amont et tu ne te retrouves pas, 'potentiellement' avec un fichier texte inexploitable par que le bonhomme aura écrit "Genre :" au lieu de "genres:", maintenant je ne dis pas que c'est la bonne solution, mais je fournis une petite explication sur le pourquoi du xml.
D'ailleurs si ce format était aussi merdique, on se demande comment il à pu envahir tout le web avec le html.
[^] # Re: XML, encore et toujours.... le mauvais choix pour la mauvaise utilisation.
Posté par freem . Évalué à 1.
Je veux bien le pourcentage d'utilisateurs du XML qui font le DTD quivabien, stp?
1%? 2%? 5%? Je ne monterai pas au-delà.
En même temps, je n'ai jamais dit qu'il est inutile.
Ce qui me fait le haïr, c'est à force de le voir partout, pour tout et n'importe quoi, fichiers de configuration y compris. Et qu'on me ressasse que c'est la perfection à longueur de temps à, comme souvent avec moi, eu l'effet inverse, qui fait que dorénavant, je commence toujours par chercher une solution autre qu'XML, et si aucune ne conviens, ce qui n'est pas commun, alors je retombe sur XML.
Au moins, moi, je suis conscient d'être un hater, je sais pourquoi, et je l'assume, contrairement aux fanboys de ce truc.
[^] # Re: XML, encore et toujours.... le mauvais choix pour la mauvaise utilisation.
Posté par Benbben . Évalué à 1.
Tu devrais peut être jeter un coup d’œil vers les microdata !
C'est du Web sémantique, HTML5, et tout ce qui est à la mode en ce moment !
Et en plus c'est pratique, si tu utilises un format standard que plusieurs utilisateurs pourront lire, ils y a plus de chance que les sites web se mettent à l'utiliser.
# cmake & multi-frontend
Posté par freem . Évalué à 1.
Au sujet du build system, je te conseille plutôt CMake, ou n'importe quel outil autre que les GNU autotools archaïques.
Pour les front-end qui varient, c'est une excellente idée, mais c'est un peu comme pour les plug-in, ce n'est pas en en faisant qu'un que tu pourras avoir une interface ( logicielle ) définitive et fonctionnelle. Ce n'est pas que moi qui le dis, lorsque que je faisais des recherches à ce sujet, je suis tombé sur divers documents, dont un de google qui indiquait en gros que les interfaces de plug-in deviennent correctes à partir de 3 plug-in. Je gage que ce sera la même chose dans ton cas, bien qu'on puisse plutôt parler de plugout, puisque c'est le moteur (transmission-common) qui est le plugin d'une interface (transmission-gtk/cli/daemon/qt).
J'ai le même sentiment a propos des applications comme mpd, bien que le use case soit très différent.
[^] # Re: cmake & multi-frontend
Posté par Kekun (site web personnel, Mastodon) . Évalué à 2.
Je jetterai un œil à CMake, j'ai essayé de comprendre Automake mais en vain jusque là…
J'en profiterai pour découvrir Qt d'autres environnements. =)
[^] # Re: cmake & multi-frontend
Posté par freem . Évalué à 2.
C'est généralement ce que je rétorque quand on me demande pourquoi je n'aime pas les autotools. J'ai dis cmake, mais ne te laisse pas faire, il y en a pleins d'autres. CMake est juste celui que j'ai testé en 1er après les autotools, parce que plus de gens font plus de bruit à son sujet.
# Re: Journal— Projet Badnik, partie 2 : GameData et appel àcontribution
Posté par Juke (site web personnel) . Évalué à 3.
Si un jeu ne peux avoir qu'un seul id pourquoi ne pas en faire un attribut de game ?
[^] # Re: Journal— Projet Badnik, partie 2 : GameData et appel àcontribution
Posté par Kekun (site web personnel, Mastodon) . Évalué à 2.
J'y ai pensé et j'ai cherché des règles et cas d'utilisation de sous éléments ou d'attributs, avant de pencher, je ne sais plus trop pourquoi, pour l'utilisation d'un sous élément… mais c'est vrai que ça serait certainement mieux en attribut, je change ça.
Merci pour ta remarque, c'est entre autre le genre de remarques sur la forme que j'espérais obtenir.
Bien sûr j'espère aussi des remarques sur le fond. =)
[^] # Re:Journal— Projet Badnik, partie 2 : GameData et appel àcontribution
Posté par Juke (site web personnel) . Évalué à 2.
De maniere generale tu peux faire ça pour toutes les propriétés uniques.
# Pourquoi un nouveau format?
Posté par MCMic (site web personnel) . Évalué à 3.
Je n'ai pas compris, quel problème cherche tu à résoudre avec ton nouveau format qui n'est pas résolu par l'existant?
Pourquoi AppData ne convient pas?
Pourquoi ne pas directement prendre les infos dans les .desktop des jeux?
Ne serait-il pas possible d'avoir un truc générique avec des modules pour les différentes sources d'info, qui permettrait de prendre l'info dans les paquets quand le jeu est un paquet, dans son fichier .desktop quand il en a un, via un émulateur pour les jeux concernés, dans un truc spécifique si besoin et qu'il est présent, …
[^] # Re: Pourquoi un nouveau format?
Posté par Kekun (site web personnel, Mastodon) . Évalué à 2.
AppData ne prend pas des problématiques propres aux jeux comme le type de contrôleurs, le nombre d'utilisateurs, les modes de jeu (local, lan…)…
Seul un très faible nombre de jeux sont distribués avec un .desktop, je pense notamment aux jeux sur consoles (qui sont distribués sous forme de binaire de rom, d'image disque…) ou autres.
C'est la solution de facilité et c'est précisément ce que j'ai tenté de faire en premier lieu et j'ai malheureusement constaté que ça ne marche pas aussi bien que prévu.
GameData est une partie de la solution que je propose pour résoudre le problème d'obtention des données : ça permet de les distribuer avec l'application gérant les jeux.
[^] # Re: Pourquoi un nouveau format?
Posté par MCMic (site web personnel) . Évalué à 2.
Ta base ne sera jamais complète, et la mise à jour des infos en fonction des sorties/mise à jour de jeu est un travail de titan, qui ne sera très probablement pas fait suffisamment régulièrement.
C'est une bonne solution d'avoir plusieurs sources parmis lesquelles figurent les émulateurs, le gestionnaire de paquet et les .desktop.
Il ne faut pas avoir de sources qui nécessitent un accès internet.
Tu peux éventuellement avoir ton système en complément pour ajouter les jeux manquants ou les infos qui ne sont pas données par les autres sources, mais ce serait mieux de prendre un standard comme le .desktop et l'étendre pour y mettre les données spécifiques aux jeux.
[^] # Re: Pourquoi un nouveau format?
Posté par Kekun (site web personnel, Mastodon) . Évalué à 2.
L'idée est de se baser sur des BDD en ligne déjà existantes et qui se sont stabilisées, et d'en récupérer les informations fondamentales.
Les émulateurs ne fournissent pas la moindre information, tout ce qu'ils ont, ils le trouvent soir dans les fichiers de jeu (autant dire dans rien du tout), soit dans des bases de données hors ligne (comme ce que je compte mettre en place).
C'est précisément un de mes buts : me passer de l'accès à internet autant que possible en fournissant en local une partie des données dans les GameData.
À quoi bon utiliser quelque chose de standard si je dois l'adapter derrière, et donc me priver de l'écosystème de ce standard ? Je ne suis pas contre utiliser un format particulier, mais ce qui compte avant tout ce n'est pas la forme mais la disponibilité des données en local.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.