Inishell est un générateur d’interfaces graphiques sous licence GPLv3 pour la configuration de logiciels utilisant des fichiers de configuration au format INI, écrit en C++ / Qt.
Sommaire
Pourquoi?
Nous avons développé une première version il y a presque dix ans de cela pour la configuration de nos modèles numériques du manteau neigeux (eux aussi en GPL ou LGPL version 3). En effet, l’une des difficultés principales des utilisateurs de modèles numériques scientifique est le choix des options de configuration qui peut avoir un impact très important sur leurs performances. Ces modèles requièrent un très grand nombre de paramètres de configuration (plus de 350 paramètres pour notre modèle Snowpack et son pré-processeur MeteoIO) qui doivent être choisis en toute connaissance de cause. Ceci se traduit directement par un grand nombre de demandes d’aide nous parvenant, leur traitement représentant de l’ordre de 75% d’un temps plein alors que notre équipe de développement atteint au maximum trois temps pleins.
Évidement, l’idéal serait que les utilisateurs lisent la documentation détaillée que nous fournissons avec nos modèles. Ce n’est malheureusement en général pas le cas, et la complexité de configuration des modèles numériques signifie que même des utilisateurs habituels vont générer des configurations moins performantes qu’attendu. La solution réside dans l’élaboration d’une interface graphique, afin d’accompagner les utilisateurs dans la configuration du modèle, de leur fournir des liens directs vers les pages de documentation et d’offrir une vue d’ensemble des fonctionnalités et capacités du modèle.
Malheureusement, créer et maintenir une interface graphique pour un très grand nombre d’options de configuration (qui plus est pouvant changer assez souvent, des options étant renommées et de nouvelles options ajoutées) représente une charge de travail inaccessible à une équipe de développement déjà insuffisante. Enfin, les compétences requises pour une telle tâche sont en général différentes des compétences des développeurs de modèles numériques…
Approche
L’approche choisie par Inishell est basée sur quelque chose comme les modèles d’interface déclarative, en simplifiant énormément le concept du fait du scénario d’usage choisi : pas de mise en page complexe, peu de diversité des éléments graphiques (il s’agit principalement d’entrer un choix parmi une liste, un chemin ou nom de fichier, une valeur numérique entière ou réelle). L’accent est mis sur le type d’entrée attendu de la part de l’utilisateur, qui générera un widget graphique (boite de saisie, boite déroulante, etc) qui lui-même émettra le bon code dans le fichier INI. La spécification des paramètres attendus de la part de l’utilisateur est faite via un fichier XML qui donne la clef de configuration, le type de donnée, quelques conditions permettant de valider l’entrée et un texte d’aide (pouvant contenir des hyperliens cliquables).
Il est donc possible d’avoir autant de fichiers XML que souhaité, et autant de modèles numériques que souhaité. Évidement, il est aussi possible de l’utiliser de la même façon pour générer des fichiers INI pour d’autres types de logiciels (par exemple, pour générer un php.ini). À l’ouverture d’Inishell, l’utilisateur doit choisir pour quelle application générer un fichier de configuration (zone 1 sur la capture d’écran). Ceci déclenche la lecture du fichier XML et la génération des widgets dans la zone 2, ou l’utilisateur peut ensuite entrer sa configuration. Celle-ci sera ensuite enregistrée dans un fichier INI, qui peut bien évidement être relue par Inishell (toute clef de configuration non reconnue, ainsi que les commentaires, sera conservée même si elle ne sera pas affichée).
À titre d’exemple, la capture d’écran montre le contenu du fichier XML permettant de générer une frame avec deux zones de saisie (un chiffre réel et un fichier). La validation des entrées utilisateur se fait via le type de donnée, les limites min/max ainsi que des expressions régulières. Il est enfin possible de lancer une application « consommant » ce fichier INI directement depuis Inishell (ou des options en ligne de commande seront aussi fournies et la sortie terminale capturée et affichée dans Inishell).
Conclusion
La version d’il y a dix ans (en Java) commençait doucement à avoir fait son temps : Java est de moins en moins disponible par défaut sur les machines de nos utilisateurs (voire vient avec ses propres bugs), il n’était pas possible de lancer des applications en ligne de commande depuis et le code n’avait jamais eu l’attention qu’il aurait dû avoir (suite à l’accident de ski de la stagiaire de l’époque!). Une réécriture complète, native et autosuffisante s’imposait donc.
Nous sommes très satisfaits de cette nouvelle version en Qt, qui nous a permis de corriger tous les défauts de l’ancienne version. Inishell est maintenant agréable d’utilisation, correctement intégrée dans les environnements des utilisateurs et pouvoir lancer les modèles directement depuis l’interface graphique est un vrai plus (ceci évite d’avoir la tentation de repasser par un éditeur de texte pour modifier le fichier INI). Nous l’utilisons maintenant quasi exclusivement (aux dépens de la console) et nos utilisateurs se laissent aussi convaincre.
Il reste malgré tout des choses en chantier : quelques bugs mineurs mais tout de même embêtants (dans certains widgets, le curseur d’édition se replace en fin de ligne après chaque appui de touche) et quelques questions plus fondamentales : les fichiers XML sont pour l’instant distribués avec Inishell, alors qu’il faudrait les distribuer avec les modèles utilisateurs. Mais dans ce cas, quelle est la bonne stratégie pour retrouver tous les fichiers XML à lire (ainsi que des fichiers XML qui appellent via un « include » le fichier XML d’un autre outil numérique). Une évolution probable sera le support de formats autres qu’INI et que d’autres outils se basent eux aussi sur Inishell!
Aller plus loin
- Publication dans Geoscientific Model Development (101 clics)
- Vidéo de présentation (2 minutes) (221 clics)
- Gitlab d'Inishell (289 clics)
- Télécharger une version précompilée (84 clics)
# Très sympathique !
Posté par jpaul . Évalué à 9.
Voilà le genre de projets que j’adore dans le monde libre. Un petit outil simple mais visiblement très puissant et qui répond à un réel besoin.
Je suis sûr que des tas de startups ont levé des millions avec moins que ça.
Je n’en ai personnellement pas l’usage mais ça reste dans un coin de mes bookmarks au cas où !
[^] # Re: Très sympathique !
Posté par Mathias Bavay (site web personnel) . Évalué à 9.
Merci!
Pour ce qui est de répondre à un vrai besoin, c'est un peu la force de notre groupe et de notre institut de recherche: nous avons à la fois des missions de recherche (sur le thème de la neige et des avalanches) et des missions opérationnelles (publication du bulletin d'avalanches pour toute la Suisse, deux fois par jour pendant tout l’hiver ou bien les risques de crues entre autres exemples de dangers naturels). Cela signifie que nous sommes les premiers utilisateurs des outils que l'on développe. Et mine de rien, cela fait une grosse différence par rapport à certains groupes avec lesquels nous avons pu travaillé qui développent des choses basées sur des concepts bien plus avancés que nous (car nous ne sommes pas un labo d'informatique) mais qui n'utilisent pas ce qu'ils font…
Et je rêve toujours de prendre le temps de faire les fichiers XML pour les php.ini afin d'avoir une interface graphique pour configurer php (mais il faut que je trouve une bonne solution à la distribution des fichiers XML pour les applications supportées avant de faire cela). En gros, cela me permettrai de faire revivre ce qui avait été mon inspiration première il y a bien longtemps (en 1996-97): The Dotfile Generator.
[^] # Re: Très sympathique !
Posté par Thomas Capricelli (site web personnel) . Évalué à 4.
C'est carrément super utile, oui. Et passer de java à Qt… c'est une évidence ;-)
# Liens en Anglais
Posté par Mathias Bavay (site web personnel) . Évalué à 4.
Est ce qu'un modérateur pourrait ajouter quelque chose comme [en] devant les liens? Tous sont en Anglais, je ne voudrais pas que certains soient déçu…
Et au passage: l'interface d'Inishell peut être traduite, il y a d'ailleurs une version en Allemand, mais je n'ai pas eut le courage de faire la version en Français sachant que tout le reste (fichiers XML, documentation en ligne) est de toute façon en Anglais.
# Expérience perso
Posté par KuroLightning . Évalué à 7.
Bonjour,
Tout d'abord merci pour ce journal et un grand bravo pour le projet. Super intéressant ! Je me joins au 1er commentaire.
Pour ma part, j'ai été confronté à ce genre de problèmes dans des conditions semblables (projets de recherche, milieu scientifique, différents profils techno-scientifiques…). En somme, j'étais chez les "numériciens" et nous avions un code de simulation de propagation d'ondes radios dans des plasmas avec ~ 50 paramètres pour gérer les simulations. Certains sont liés à la physique (rayon de la Terre, nature du sol, du plasma…) d'autres aux numériques (méthode d'interpolation, choix du solveur matriciel…) et aux hardware (archi cpu, nombres de coeurs, taille des caches…). Tout comme vous, ce code devait être utilisé par des expérimentateurs voir des théoriciens. Bref, des gens qui ne sont pas toujours à l'aise avec ce genre d'outils. Afin de réduire le nombre d'appels à l'aide pour le réglage du modèle avant simulation (surtout les questions numériques et hardware), un stagiaire (talentueux) avait développé un outils similaire (avec des technos web) pour faciliter la création du fichier de conf.
Ainsi, nous nous étions amusé à récupérer toute les fichiers de configurations produits ainsi que les critères de performance de sortis du code (basé sur le temps de calcul de certaines routines, la consommation mémoire, cpu…) afin de produire une IA (c'est que l'on dira en start-up Licorne nation)[Mais entre nous un pauvre modèle à apprentissage supervisé] dont le but était de faire DAO pour nos collègues. Ainsi, ils leur suffisait d'indiquer certaines options pourvoir les prédictions des performances, ou à l'inverse, de demander tel performance pour obtenir une configuration adapté. Si au début de l’essai, ce ne fut pas superbe. Au bout de quelques semaines d'utilisation l'outil était devenu indispensable et énormément appréciée, en plus de s'améliorer avec le temps. Et bien évidemment, les sollicitations étaient relatifs aux modèles plus qu'à son utilisation.
Si ça peut-être utile d'une quelconque façon… Mes 2 cents.
[^] # Re: Expérience perso
Posté par Mathias Bavay (site web personnel) . Évalué à 3.
Cet aspect est très important: nos utilisateurs vont de la personne qui ne parviens pas à trouver un logiciel dans le menu démarrer de Windows 8 (je sais, ce n'est pas un critère, le dit menu est tellement mal fait que ce n'est pas étonnant!) à la personne qui bidouille directement le code source avant même d'avoir lu la moindre doc… Ce qui cause aussi souvent des problèmes.
Mais il y a un autre aspect qui joue un rôle énorme, c'est la complexité intrinsèque du domaine d'application du logiciel: quelle paramétrisation du rayonnement thermique devrais-je utiliser dans ma simulation? Quelle paramétrisation pour la densité de neige fraîche? Et là, avoir la doc qui s'ouvre directement à la bonne page en un clic à côté de la boite de dialogue pour configurer le paramètre, c'est super confortable. Sans compter que même si j'ai fait plus de 90% de l'implémentation de certains outils, je suis incapable de me souvenir précisément de quelles options sont disponibles et du nommage précis de ces options (même si nous avons beaucoup travaillé sur les noms afin que quelqu'un qui lira un fichier de configuration dans plusieurs décennies puisse comprendre ce que cela signifie)… C'est aussi ce qui ressort de l'un des papier que je cite dans notre publication: la ligne de commande (ou l'édition directe de fichiers de configuration) est très efficace pour les choses que l'on utilise très souvent, mais dès que cela devient un peu plus occasionnel, on perd très vite en efficacité (on ne se souvient tout simplement plus).
C'est effectivement une bonne idée! Maintenant, cela me tente d'essayer ce genre d'approche pour aider les utilisateurs (moi même y compris) dans l'utilisation des modèles… Au moins pour mettre sur la bonne voie.
[^] # Re: Expérience perso
Posté par Claude SIMON (site web personnel) . Évalué à 5. Dernière modification le 02 février 2022 à 11:17.
Sans vouloir me faire de publicité (un peu quand même), un de mes projets (le toolkit Atlas : https://atlastk.org) a été développé pour répondre à ce genre de problèmes. L'approche est de réutiliser au maximum l'existant, mais en en simplifiant l'utilisation, autant en terme de programmation qu'en ce qui concerne l'infrastructure à mettre en place.
L'interface est ainsi "dessinée" en HTML, qui est quand même assez simple à mettre en œuvre, et pour lequel on il existe une documentation foisonnante, mais les actions associées aux évènements de l'interface, ainsi que sa mise à jour, sont codées dans le langage de son choix, ce choix étant, à ce jour, limité à Java, Node.js, Perl, Python et Ruby. C'est, certes, plus compliqué, en terme de programmation, que la solution présentée dans ce journal, mais c'est, en contrepartie, nettement plus polyvalent.
Grâce au cloud computing, pour reprendre un terme à la mode, le toolkit Atlas en lui-même est très léger (quelques dizaines de Ko) et absolument sans aucune dépendance. Pas de toolkit graphique à installer (exit Qt, GTK…) ; tout se passe dans le navigateur web, sans avoir de serveur web à installer (et il n'est pas non plus embarqué dans le toolkit). Il suffit d'être connecté à Internet.
Et pour ceux qui le désirent, à l'instar d'un certain nombre d'utilisateurs du toolkit Atlas, toute la partie dans le cloud peut-être installée sur le serveur de son choix.
Pour nous émanciper des géants du numérique : Zelbinium !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.