YunoHost Apps
(Je trouve ca clair, cohérent avec le langage utilisé dans le forum et la doc, et puis bilingue …)
Pour en revenir au fond, que pensez-vous de mes remarques sur la charge supplémentaire pour le mainteneur ?
Car pour moi plus on alourdi/allonge la procédure pour porter une app, plus on met de barrière à l’entrée et donc on réduit l’offre pour l’utilisateur final.
+1. De mon point de vue avoir une image, une icone ou un lien vers une demo doit rester optionnel, à la fois pour limiter la charge de travail et pour rester compatible avec les apps existantes…
Je suis d’accord aussi.
La liste des apps se base sur les manifest et permet déjà de récupérer pas mal d’infos.
Pour tout ce qui est changelog, icone, démo, screenshots, ça ne devrait être affiché que si ils sont présent.
Et ça pourrait être requis pour les apps officielles.
Mais inutile de surcharger les packageurs occasionnels, qui ont déjà beaucoup à faire.
Et étant le nombre d’app qui sont peu ou pas maintenues, on en perdrait beaucoup à l’exiger de toutes les apps.
1 Like
Et pis un changelog peut se récupérer directement du github, par exemple. Ce qui évite de le maintenir à jour à deux/trois endroits différents.
Tu veux dire le générer depuis la liste des commits ?
Ou avoir un changelog dans le package ?
Un changelog me parait bien, mais il faut prendre la peine de le maintenir à jour.
Si le mainteneur tient déjà à jour un changelog, ça se récupérera tout seul.
Évidemment c’est à condition qu’il le tienne à jour, mais c’est valable de manière générale pour savoir quelles sont les nouveautés. Ça peut être une sorte de bonne pratique à mettre en valeur.
Depuis la liste des commits, bof, ça sera probablement illisible/incompréhensible par l’utilisateur.
Et pour la capture d’écran comme sur la proposition, comment ça serait géré ? Une image d’un format standard dans le dépôt github ?
Ou y aurait-t’il un dépôt spécial pour cette fonction ?
Ajouter les screenshots dans le dépôt me semble plutôt une bonne idée.
Mais ça pose un problème, lorsque la liste est générée (à ma connaissance), seul le manifest est récupéré.
Je pense toutefois que ça pourrait être l’occasion de cloner l’ensemble des dépôts sur un de nos serveurs, afin de générer des urls pour ces images d’une part. Et garder une sauvegarde de chaque dépôt d’autre part.
Car en l’état, nous n’avons aucune sauvegarde des dépôts d’app.
Justement, chercher en plus une capture d’écran dans le dépôt, si disponible, ça ne casse pas la compatibilité, et c’est un rien à rajouter.
Après peut-être que le manifeste pourrait contenir une url pour aller chercher l’image. (ex: si c’est une image du site officiel)
Ça me semble être un autre problème, de garder l’historique et une sauvegarde indépendante du mainteneur et de github, et ça pourrait se régler simplement en paramétrant une copie des dépôts github.
Hum.
Moi j’aime bien YunoApp (ou YunoApp’s) comme nom. En plus, c’est à la fois une réduction/contraction Française qu’une appellation Anglaise.
Cela fait ni kiosk, ni market, mais c’est bien la liste des app de Yunohost, et c’est un nom court à utiliser dans une discussion à bâtons rompus.
Le nom ne ferait aucun doute quant au sujet abordé et je pense que vous pouvez tous vous retrouver dans cette appellation.
1 Like
Si je ne fais pas d’erreur, c’est ce script python qui récupère les infos.
Je connais pas python, mais je crois comprendre ici que seul le manifest est téléchargé.
Oui, mais là on parle d’un ajout. C’est un rien à faire de tester si un fichier Screenshot.jpeg est disponible, ou de regarder dans le manifest quelle est l’url de l’image.
Regarder dans le manifest serait certainement simple, par contre vérifier la présence de l’image sur le dépôt peut, peut-être, poser un problème car il y a une limite de requêtes sur github.
Et ce script fait déjà beaucoup de requêtes.
@Bram saurait nous en dire plus sur ce point, c’est lui qui m’avais expliquer ce problème.
J’ignore si une requête sur un même dépôt pose le même problème, mais j’imagine que oui.
Auquel cas, la limite serait aussi bloquante si l’image est hébergée dans le dépôt (mais qu’on regarde dans le manifeste). C’est pas comme pour l’installation ou l’on peut télécharger l’archive et bidouiller ensuite.
Hey !
Sympa ce petit topic @heyyounow ! 
Je vais essayer de retravailler sur une maquette (fonctionnelle cette fois, haha) qui puisse prendre en compte les tags, et divers infos sur les tuiles d’app.
Très bonne idée, ce qui pourrait être pas mal serait de concevoir une petite interface “mainteneur” où il n’aurait qu’à drag/drop tous ces fichiers pour ajouter une app et qui lui permettrait de voir quelles applications ne sont plus compatibles/mettre en maintenance certaines etc…
Bon ça me semble un peu complexe à mettre en place mais ça me botterait bien 
Pour ce qui est des screenshots, et icon des applications je pensais faire un template (.psd/.gimp/.sketch etc…) pour faciliter le travail des mainteneurs. Pour ce qui ne souhaitent pas mettre de screenshots/icons on pourra faire un petit icon par défaut l’histoire de pas casser la structure globale !
Y’en a-t-il besoin ? Si c’est comme sur ta maquette actuelle, une simple image carrée d’une dimension fixe, je ne pense pas. Quitte à ce quelques effets (type joli contour ) soient ajoutés par défaut autour de la capture.
Par contre ça pourrait être sympa de pouvoir la cliquer pour la voir en plus grand, et en voir d’autres au passage.
Premier exemple qui me vient à l’esprit: pour Own/Nextcloud on pourrait montrer plusieurs vues et cas d’usage.
Et la question qui va déchaîner les foules: les captures d’écrans, en quelle langue ? 
Ben les deux premières lettres 
C’est pas fondamentalement bloquant mais ça demandera du boulot en plus car y a pas mal de façons de gérer ça (mais je ne pense pas que ça soit le bon endroit pour rentrer dans les détails techniques).
Si je dois ressortir ma casquette “opérationnelle” (mais c’est un autre temps de réflexion que celui que vous avez là maintenant) : oui c’est faisable, non ça ne sera probablement pas dès le début/une priorité, je recommanderai vraiment de découper ce travail en de nombreuses étapes et déjà changer le css sera une belle avancé. Les (nombreuses) petites améliorations viendront progressivement.
Sinon je rejoins beaucoup toutes les personnes qui insistent pour qu’on ne complique pas le travail des mainteneurs d’applications outre mesure. Une des grandes forces de YunoHost est la facilité avec laquelle on peut faire une application, il est important que ça le reste.
Idem pour la rétrocompatibilité.
En tout cas ce boulot est très cool
We could use Sandstorm app market sources.
Gros + 1