+- PrimTux, la distribution éducative (https://forum.primtux.fr)
+-- Forum : PrimTux: LA DISTRIBUTION: présentation, aide et développement (https://forum.primtux.fr/forumdisplay.php?fid=5)
+--- Forum : Demandes d'évolution - Tests des iso - Développement (https://forum.primtux.fr/forumdisplay.php?fid=10)
+--- Sujet : Evolution des Handy-menu (/showthread.php?tid=864)
Evolution des Handy-menu - Steph - 07-10-2018
Ça ne va toujours pas, à moins que je ne me sois trompé dans ma compilation, mais j'ai remplacé les fichier là où ils étaient...
Code :
administrateur@primtux:/usr/local/bin/primtux$ ./handymenu-prof
[Errno 2] Aucun fichier ou dossier de ce type: '/etc/handymenu/handymenu-prof.yaml'
Traceback (most recent call last):
File "./handymenu.py", line 20, in <module>
main(arg, config_path)
File "/usr/share/handymenu/lib/handymenu_app.py", line 318, in main
menu = Handymenu(appname, config_path)
File "/usr/share/handymenu/lib/handymenu_app.py", line 307, in __init__
self.window.set_icon_from_file(self.utils.primtuxmenuicon)
AttributeError: Utils instance has no attribute 'primtuxmenuicon'Et il n'y a aucun handymenu qui démarre.
Evolution des Handy-menu - mothsart - 07-10-2018
Lol, non mais merci de votre soutient. :lol:
Voici le nième correctif : https://framagit.org/Steph/handymenu-primtux/merge_requests/21
Ah, si vous saviez ce que ça donne des livraisons de gros softs en prod. (faut aimer les JO avec des épreuves surprises)
C'est plus le sentiment que ça procure après livraison :
imagine que ça m'arrive encore souvent avec de l'expérience à tester 1000 fois tout en corrigeant... à passer un temps fou à réfléchir à tous les scénarios possibles et une fois que tu livres, le premier utilisateur qui passe par là te remonte un bug en 5 secondes chrono.
On apprend l'humilité en quelque sorte.
Après, je me mets des fois tout seul la pression en voulant sauter le 2m alors qu'on me demande simplement de passer le 1m50.
Evolution des Handy-menu - Steph - 07-10-2018
Et là tu touches du doigt l'importance de la complémentarité entre les collaborateurs et du travail en équipe.
Evolution des Handy-menu - mothsart - 07-10-2018
Ouais, on va dire ça pour me rassurer : j'ai plus l'impression de vous faire perdre votre temps en testant des trucs à moitié fini, snif.
Evolution des Handy-menu - Steph - 07-10-2018
Sûrement pas! Tu peux me présenter le gars qui a envoyé un soft nickel du premier coup?
Evolution des Handy-menu - Steph - 07-10-2018
Bon ça marche! :lol: J'aurais juste aimé que la coche de fermeture soit activée par défaut. Là j'ai mis un noclose.conf dans les home, mais il faut quand même cocher pour que ça soit pris en compte. Sans noclose.conf c'est pris en compte une fois, avec, c'est pris en compte tout le temps. En gros j'aurais mieux aimé avoir le contraire: fermeture après démarrage d'une application par défaut / resté ouvert une fois si décoché.
Evolution des Handy-menu - Philippe Dpt35 - 07-10-2018
mothsart a écrit :Ouais, on va dire ça pour me rassurer : j'ai plus l'impression de vous faire perdre votre temps en testant des trucs à moitié fini, snif.Moi, ce qui m'étonne, c'est qu'on ait pas plus de retours de bugs que ce qu'on a compte-tenu de tout ce qu'on développe en nombre de versions, plateformes et outils divers !!!
Evolution des Handy-menu - Philippe Dpt35 - 08-10-2018
Puisqu'on est dans les handymenus, et qu'il faudra refaire un paquet, il faudrait changer l'architecture. Il est en effet marqué all, et il nous faut une version différente pour le RPi compte-tenu des applications qui ne sont pas portées sur arm (logiciels omega, calcul@TICE pour lequel nous n'avons pas de nouvelles, ...)
Evolution des Handy-menu - mothsart - 08-10-2018
C'est peut-être possible d'avoir un seul source pour les 2 paquets avec un script qui se déclenche si on est dans le cadre de l'arm... y'a même peut-être une astuce de sioux made in debian.
C'est sur, que dans l'idéal n'avoir qu'un seul paquet qui s'adapte, c'est mieux.
Bon, c'est aussi possible d'adapter les handymenus (comment se tirer une balle dans le pied) :
1. On met les fichiers de conf en plus dans le script handymenu.install : https://framagit.org/Steph/handymenu-primtux/blob/master/debian/handymenu.install#L14
2. le handymenu, au lancement regarde son archi et si c'est de l'arm, il rajoute un suffixe au fichier de conf :
handymenu-mini.rpi.default.yaml et handymenu-mini.rpi.yaml par exemple.
Pour ta modif, je regarde ça dans la semaine Steph...
Evolution des Handy-menu - Philippe Dpt35 - 08-10-2018
Une meilleure solution serait peut-être de faire une telle opération en script de post-installation du paquet. Ainsi il n'est pas nécessaire de le faire à chaque lancement du handymenu.
On place des fichiers config handy-mini-pc.yaml, handy-mini-rpi.yaml, handy-super-pc.yaml,etc. mais pas de fichiers handymenu-{mini,super,maxi,prof}-default.yaml dans les fichiers de config.
Le script teste l'architecture, et renomme les fichiers handy-mini-pc.yam ou handy-mini-rpi.yaml, etc en handymenu-mini-default.yaml.
Dès lors pas besoin de modifier le script python.
Evolution des Handy-menu - Philippe Dpt35 - 08-10-2018
Mieux: on laisse les fichiers de configuration tels qu'ils sont, qui sera ainsi la configuration par défaut.
Le script de post-installation teste si on est sur architecture arm. Si c'est le cas les fichiers handymen-mini-rpi.yaml etc. sont renommés pour prendre la place des handymenu-mini-défaut.yaml
, etc.
Evolution des Handy-menu - mothsart - 09-10-2018
J'ai édité le postinst des handymenus pour inclure cette règles : https://framagit.org/mothsart/handymenu-primtux/blob/master/debian/handymenu.postinst
Il me manque les 4 fichiers de conf, Philippe.
Evolution des Handy-menu - Philippe Dpt35 - 09-10-2018
Voici les fichiers de conf:
http://www.primtux.fr/Documentation/armhf/handymenu-rpi.yaml.tar.gz
Ton lien vers le postinst ne fonctionne pas. Les handymenus ne sont pas plutôt dans le dépôt /Steph/primtux ? Mais là je n'ai pas non plus réussi à le trouver.
Evolution des Handy-menu - ideefixe - 09-10-2018
une licence libre sera-t-elle attribuée au HandyMenu-PrimTux
Citation :No license. All rights reserved
exemple : LICENSE PrimTux-Eole
Evolution des Handy-menu - mothsart - 09-10-2018
Yep Philippe : le dépôt était privé : (là ça devrait fonctionner) https://framagit.org/mothsart/handymenu-primtux/blob/master/debian/handymenu.postinst
Les sources du handymenu sont bien chez Steph mais je ne publie pas directement sur son dépôt.
J'utilise le principe décentralisé de GIT : je crée ma branche avec mes correctifs et une fois que j'ai tout (en l’occurrence, ici les fichiers + le postinst) je créee une PR et Steph s'occupe de merger ma demande.
Du coup, c'est à Steph (même si il m'a donné les droits de merge) d'approve mes modifs avant de les intégrer : ça force la relecture du code donc la qualité.
Pour l'instant, c'est anecdotique mais si un nouveau venait à contribuer, il le pourrait sans qu'on lui donne des droits d'écritures : il suffit pour lui de cloner le dépôt, de faire sa modif et de la proposer.
Après, à nous d'estimer si elle est pertinente en l'état, dans quel version on l'intègre etc.
Ideefixe : je suis assez partisan de la licence BSD : c'est compatible avec la GNU tout en étant plus permissive.
De toute façon, les handymenus ont tellement été travaillé dans l'optique de Primtux qu'il faudrait fournir un gros effort pour les utiliser dans un autre cadre.
Evolution des Handy-menu - Philippe Dpt35 - 09-10-2018
Pour le RPi, ce que renvoie uname -m me pose question. Est-ce bien toujours armv7l pour toutes les versions ? RPi2, RPi3, RPi3B+, et celles à venir ?
Evolution des Handy-menu - Steph - 09-10-2018
Là je n'ai rien dans les dépôts concernant un handymenu armhf, c'est normal?
Evolution des Handy-menu - Philippe Dpt35 - 09-10-2018
Oui, c'est normal, j'utilise la version marquée all sur le dépôt principal. La solution qu'on est en train de mettre en oeuvre permettra d'éviter d'avoir un paquet spécifique pour RPi, et facilitera la maintenance.
Pour ce que renvoie uname -m, je pense qu'il serait plus prudent de tester non pas "armv7l", mais seulement les 3 ou 4 premières lettres avec un pipe vers cut (arm ou armv).
Evolution des Handy-menu - mothsart - 09-10-2018
Bien vu Philippe : vu que j'ai les 3 variantes, j'ai lancé Primtux sur chaque et la rpi 2 est effectivement différente : "armv6l".
Evolution des Handy-menu - mothsart - 09-10-2018
Ideefix : si on regarde dans le code, il reste des infos de licence : https://framagit.org/mothsart/handymenu-primtux/blob/master/lib/handymenu_app.py#L32
Evolution des Handy-menu - mothsart - 09-10-2018
Voilà, Steph : je t'ai poussé 2 PR : une pour la prise en charge de la rpi et l'autre pour le correctif demandé sur la fermeture après lancement.
Evolution des Handy-menu - ideefixe - 09-10-2018
mothsart a écrit :Ideefix : si on regarde dans le code, il reste des infos de licence : https://framagit.org/mothsart/handymenu-primtux/blob/master/lib/handymenu_app.py#L32
Oui :
Code :
licence = "GPLv3"
homepage = "http://handylinux.org, http://primtux.fr"Sauf que le site handylinux.org n'existe plus !
J'ai trouvé ceci https://git.framasoft.org/handylinux/debdev/tree/master/handymenu
Evolution des Handy-menu - mothsart - 15-10-2018
J'aimerais bien un avis contraire mais en migrant ma primtux 2, j'en ai profité pour tester les configs des nouveaux handymenus et je crois bien que le drag and drop des onglets ne s'enregistre pas.
Je vais corriger ça.
Evolution des Handy-menu - Philippe Dpt35 - 15-10-2018
Désolé de confirmer !
Evolution des Handy-menu - mothsart - 16-10-2018
Je viens de corriger : régression lié à l'ajout potentiel d'une image dans le titre de la section. ça a changé la hiérarchie des noeuds GTK et patatra : le nom de la section récupéré était vide et par conséquent ça sautait l'enregistrement.
J'ai passé le soft en 1.2.2 : y'a plus qu'à merge et à mettre le nouveau paquet dans les dépôt.