Re: [EGD-discu] ergodox

[ Thread Index | Date Index | More ergodis.org/discussions Archives ]


Je suis actuellement un train de réfléchir sérieusement à coder un gestionnaire de clavier pour mon futur clavier ergo. Le but étant de transformer un keycode (emplacement de touche) en suite de symboles. Il serait donc aussi bien utilisable en temps que firmware sur un clavier avec des fonctions avancé qu'en temps que remplaçant pour xkb. J'en ai déjà parlé il y a quelque temps sur le forum, et ça avance. J'ai enfin une solution qui me parait viable. Donner moi un moi pour faire une version de démo (histoire de voir si mon proto sur papier tiens la route), et je vous en reparle (c'était de toute façon prévu). Je pense le coder en C pour la compatibilité, même si j'aurais préféré le faire en c++.


Le 5 mai 2014 07:32, Julien Blanc <whity@xxxxxxx> a écrit :
Le 04/05/2014 20:56, sinma a écrit :

On 2014-05-03 19:53, Arathor wrote:
Le 30/04/2014 11:46, sinma a écrit :

leurs propres formats de données et donc leur propre analyseur
syntaxique (qui fait beaucoup de lignes et produit des messages
d’erreur pourris, chose qu’on pourrait s’épargner en utilisant du XML
ou du JSON par exemple).

Comme analyseur syntaxique, il y a aussi
http://www.hyperrealm.com/libconfig/

qui me semble préférable à XML

On dirait du JSON avec la possibilité de mettre des commentaires dans les données, ce qui me fait penser du coup que JSON ne peut pas être utilisé à moins d’enlever les commentaires et de les mettre ailleurs où de supprimer les commentaires avant d’analyser la syntaxe.

De mon point de vue, la syntaxe pourrie n’est que le sommet de l’iceberg. C’est plutôt conceptuellement qu’il y a des soucis (trop grande complexité pour aucun bénéfice), et donc en premier revoir ce point, décider des contraintes à garder et celles à faire sauter, et refaire quelque chose de propre à ce niveau (bien évidemment, en impliquant les dev actuels). Le format de fichier des fichiers de conf c’est dans un deuxième temps (json ne supporte pas non plus les inclusions, ça veut dire qu’il faut rajouter un mécanisme d’héritage en plus, ce n’est pas énorme mais ça fait encore un point négatif).

Il y a au moins un avantage dans le cas présents : les dev sont tout à fait conscients que le truc actuel est à revoir, seul le temps manque. Du coup la négociation devrait être faisable si quelqu’un arrive avec quelque chose qui tient la route et beaucoup de motivation.

julien


--
Pour vous désabonner, envoyez un message avec comme objet "unsubscribe"
vers discussions-REQUEST@ergodis.org




--
Robin Moussu

Délégué 1A filière PET-D

École d’ingénieur PHELMA - Grenoble INP



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/