Evolution des Handy-menu

[mothsart]

Je viens d'avoir un soucis lié au manque de conflit des handymenus sur la rpi (mais j'ai eu la même sur une pi 2 amd64) : il y a bien des conflits avec "handymenu-mini-primtux2", "handymenu-maxi-primtux2" et "handymenu-super-primtux2" mais pas avec "handymenu-primtux2".

Hors, j'ai beau regarder les sources, et je ne vois strictement aucun conflit de gérer dans https://framagit.org/Steph/handymenu-pri...an/control

J'en déduis que tu as tes propres source du coup Steph ?
Si oui, est-ce possible d'éditer le fichier sur le dépôt handymenu et de mettre à jour le dépôt ?

[mothsart]

Je viens de te faire une PR pour une 1.2.3 Steph : j'ai vu que les fichiers de conf yaml par défaut avait un reste d'encodage python.
Ca n'a pas d'impact niveau fonctionnement mais si quelqu'un s'amuse à les éditer à la main, il risque de ne pas comprendre donc autant enlever cette scorie avant de sortir la Primtux 4.

Et je m'arrête, promis.

[mothsart]

Bon, il y avait des conflits git : du coup, j'ai résolu et mergé à ta place.

[Philippe Dpt35]

Mothsart, en testant la migration d'une PTX2 RPi aujourd'hui, j'ai eu l'erreur suivante lors de la mise à jour du paquet handymenu:

Code :

Paramétrage de handymenu (1.2.2.2) ...
mv: impossible d'évaluer « handymenu-mini.rpi.default.yaml »: Aucun fichier ou dossier de ce type
dpkg: erreur de traitement du paquet handymenu (--configure) :
le sous-processus script post-installation installé a retourné une erreur de sortie d'état 1
Des erreurs ont été rencontrées pendant l'exécution :
handymenu

[mothsart]

J'ai proposé un correctif de ce genre il y a une semaine de souvenir. (fichier postinst : https://framagit.org/Steph/handymenu-pri...6807a7fc7) avec la recommandation de le renommer en 1.2.2.1
Est-ce que les dépôts ont été mis à jour en conséquence, Steph ?

[Steph]

Fichier control de la version actuelle sur le dépôt:

Code :

#!/bin/sh

set -e

USER="administrateur"
  
if id -u $USER > /dev/null 2>&1; then    
    chown ${USER}:${USER} /etc/handymenu/
fi

if test `uname -m|cut -c1-3` = "arm"; then
    cd /etc/handymenu
    mv handymenu-mini.rpi.default.yaml  handymenu-mini.default.yaml
    mv handymenu-maxi.rpi.default.yaml  handymenu-maxi.default.yaml
    mv handymenu-super.rpi.default.yaml handymenu-super.default.yaml
    mv handymenu-prof.rpi.default.yaml  handymenu-prof.default.yaml
fi

Contenu de /etc/handymenu:

[mothsart]

Bon, ben : c'est limpide : je te fais un correctif.
En revanche, va falloir que je reparte d'une primtux clean pour mes tests car je devais avoir les fichiers au bon endroit pour ne pas m'en rendre compte.

[mothsart]

voilà : désolé.

[Steph]

Non mais c'est bon on s'amuse, pas de pression.

[Philippe Dpt35]

Bon, désolé de revenir à la charge,mais là j'ai

Code :

Paramétrage de handymenu (1.2.2.3) ...
mv: impossible d'évaluer « handymenu-mini.rpi.yaml »: Aucun fichier ou dossier de ce type

[mothsart]

Bon, nième correctif.

[Philippe Dpt35]

ça s'est mis à jour.

En revanche, sur le RPi, je n'ai pas le bon fichier de configuration. J'ai toujours les entrées pour les logiciels Omega que j'avais supprimées des fichiers handymenu-xxx.rpi.yaml

En vérifiant les sources, ils sont bien présents et corrects. Mais ils n'ont pas remplacé les fichiers par défaut.

Mais j'ai travaillé sur la PTX2 RPi que j'ai migré hier, et sur laquelle il y a eu les diverse tentatives de mise à jour du handymenu.

Je dois tester la migration d'une PTX3 RPi aujourd'hui. Je verrai si le problème subsiste avec la dernière mise à jour du handymenu.

[Philippe Dpt35]

C'est bon, j'ai bien les bons fichiers de configuration sur la PTX3 migrée.

En revanche, je viens de m'apercevoir que dans les sessions élèves, j'ai la fenêtre d'accueil qui s'affiche au lieu du handymenu. C'était vrai avant la migration. C'était donc un bug sur la version RPi, et qui nous avait échappé.

[Philippe Dpt35]

En revanche, je viens de m'apercevoir que dans les sessions élèves, j'ai la fenêtre d'accueil qui s'affiche au lieu du handymenu. C'était vrai avant la migration. C'était donc un bug sur la version RPi, et qui nous avait échappé.

Fausse alerte. J'ai travaillé depuis une image qui traînait sur mon disque dur, et qui apparemment n'était pas bonne !
Voilà ce que c'est quand on ne fait pas le ménage au fur et à mesure !

[mothsart]

Ah, ouf.

[mothsart]

Je viens de refaire le tour des handymenus (en les maltraitants). Je suis tombé sur un lot de petits bugs :-{ mais aussi, j'envisage de les améliorer (sans pression, c'est pour la Primtux de l'année prochaine).

Voici les évolutions des Handymenus à prévoir.
Je ne suis pas fermé bien entendu à discussion, ajouts, autre priorité etc.


1.2.x : correctifs de bugs (si possible à effectuer dans la fin de l'année)

- Le drag and drop des sections peut avoir un effet indésirable sur les boutons "supprimer une section", "monter/descendre une section".
- Le drag and drop des sections affiche un carré blanc sur la section draggé.
- Déterminer un nombre max de softs par section : les handymenus sont extensibles alors que la config non.
- Le drag and drop d'application a quelques soucis
- ajouter un dialogue de confirmation sur la réinitialisation

- une action non encore identifié à provoqué :

Code :

/home/jferry/Desktop/primtux/handymenu/handymenu/lib/handymenu_configuration.py:431: GtkWarning: gtk_box_pack: assertion 'child->parent == NULL' failed
  hb.pack_start(addbtn)
/home/jferry/Desktop/primtux/handymenu/handymenu/lib/handymenu_configuration.py:668: GtkWarning: gtk_box_pack: assertion 'child->parent == NULL' failed
  self.mainbox.pack_start(self.addbox)
/home/jferry/Desktop/primtux/handymenu/handymenu/lib/handymenu_configuration.py:706: GtkWarning: Invalid icon size 64

  self.window.show_all()
/home/jferry/Desktop/primtux/handymenu/handymenu/lib/handymenu_configuration.py:375: GtkWarning: Invalid icon size 64

1.4.x : nouvelles fonctionnalités

- édition du logo du handymenu : principalement dans le cadre des handymenus personnalisés ou de l'ajout d'utilisateurs
- Pouvoir glisser une application directement dans la zone
- l'ajout d'une application propose un dialogue intermédiaire lorsque l'application existe déjà dans le handymenus du style :
"cette application existe déjà dans la section xxx : désirez-vous l'avoir en doublon ?"
- la croix de fermeture du handymenu-mini pourrait être plus gros.
- ajouter des images à toutes les sections du handymenu-mini : vu que la cible ne sait pas ou peu lire.

2.X

- une interface d'édition la plus proche du handymenu final :

* menu horizontal et non vertical
* petit bouton intégré (une croix) à l'onglet de la section pour le supprimer
* des flèches à gauche et à droite du menu pour déplacer l'onglet de section sélectionné
* le double-clic sur une section permet de la rééditer (un nom vide étant interdit, si il y a perte de focus on redonne le nom précédent)
* un bouton d'ajout de section crée un onglet vide avec le focus pour l'éditer. (si on ne lui donne aucun nom, elle disparait)

- plus aucune action ne devrait rafraichir l'interface. (réinitialiser par exemple)

- éviter d'ouvrir une fenêtre à l'édition,
un clic fait apparaitre :
* un bouton de suppression en haut à gauche
* la possibilité d'éditer le nom

le double-clic ouvre la boite de dialogue de changement d'icône

- garder un historique de modification et permettre "annuler/rétablir"
- rajouter des raccourcis clavier pour les utilisateurs expérimentés (par exemple, les entreprises qui installent primtux dans les écoles)
- http://forum.primtux.fr/viewtopic.php?pid=15063#10

[Steph]

Tout un programme!
Si ça peut te donner des idées, au début je cherchais une interface à la ubuntu-netbook-remix:
https://www.wired.com/2008/06/ubuntu-s-n...-promises/
Alors évidemment il se basait sur les .desktop, pas de configuration, mais l'allure me plait bien.

Vraiment d'accord avec ces idées:

- Déterminer un nombre max de softs par section : les handymenus sont extensibles alors que la config non.
- Pouvoir glisser une application directement dans la zone

Ça c'est pas mal!

- garder un historique de modification et permettre "annuler/rétablir"

[Philippe Dpt35]

Si j'ai bien compris le fonctionnement des nouveaux handymenus, lorsque l'utilisateur les modifie, cela crée un fichier personnalisé dans son home.

Or l'installation des logiciels complémentaires ne modifie que le fichier de configuration par défaut dans /etc/handymenu, et ne touche pas aux fichiers des home.

Dès lors cela ne devrait pas faire perdre les personnalisations faites par les utilisateurs.
En revanche, si c'est bien le cas, les nouvelles entrées des logiciels complémentaires ne devraient pas être prises en compte s'il y a eu personnalisation.

[mothsart]

Alors, non : ça n'écrit pas dans le home mais bien dans /etc/handymenu/handymenu-{PROFIL}.yaml dès qu'on est sur les 4 profiles.
En revanche, pour les ajouts de nouveaux utilisateurs, les handymenu se baseront sur la config du home effectivement.
Le fichier /etc/handymenu/handymenu-{PROFIL}.default.yaml lui est en readonly et sert de config par défaut (quand le fichier n'a pas été personnalisé)

En revanche, si c'est bien le cas, les nouvelles entrées des logiciels complémentaires ne devraient pas être prises en compte s'il y a eu personnalisation.

C'est une solution intermédiaire viable effectivement : n'écrire dans /etc/handymenu/handymenu-{PROFIL}.yaml que quand il n'existe pas.

[Philippe Dpt35]

Ou, quand il existe, dans le script de postinstall des paquets logiciels-primtux-{PROFIL}, demander confirmation à l'utilisateur avec un message du genre:

Le paquet xxx souhaite installer une version mise à jour de la configuration du handymenu {PROFIL} intégrant des entrées pour les nouveaux logiciels installés. Or vous avez modifié cette configuration. Souhaitez-vous conserver votre fichier de configuration, ou le remplacer par celui proposé par le développeur ?
Remplacer (O/N) ?

[mothsart]

C'est une bonne idée. J'ai jamais fait (les boites de dialogues) : si tu as une proposition de script postinst, n'hésites pas.
Faudra partager le .deb déjà et faire des tests en local avant de diffuser...

[Philippe Dpt35]

ça peut aussi se faire en mode console.

Je peux faire ça. Il faudra d'ailleurs le faire pour les versions PC et RPi qui ont des paquets différenciés par l'architecture puisque ce ne sont pas les mêmes logiciels complémentaires qui sont installés.

Mais je ne pourrai pas m'y mettre avant mercredi prochain. Il n'y a de toute façon pas urgence.

[Steph]

Faites ce que vous voulez, mais pas de machine à gaz avec plein de questions et des paramètres en veux-tu en voilà, PrimTux, c'est simplicité avant tout. J'ai rebricolé un windows cette semaine, UNE PURGE, plein de tucs qui ne servent qu'à ralentir le système.

[Philippe Dpt35]

Non, pas de machine à gaz. C'est important de demander l'accord de l'utilisateur avant d'écraser un fichier de configuration qu'il aurait pu modifier.

[Steph]

Écraser ça ne va pas, j'aime mieux la fusion. Si l'utilisateur a installé un logiciel qui est dans la logithèque Debian et qui n'est pas dans les logiciels supplémentaires, sa personnalisation sera écrasée (exemple: ideefixe et shutter).

On en vient à un problème que j'ai rencontré dès le début de PrimTux et qui m'avait carrément fait modifier les catégories des applications Linux (ce que l'on m'a évidemment reproché...) et ne pas utiliser le handymenu au départ, mais la fonction d'affichage des applications de pcmanfm, qui comprend une fonction "cacher". Le handymenu ne va pas chercher les .desktop, et les sous-catégories telles français, maths... N'existent pas dans le système Linux (enfin dans org.freedesktop machin chose). Présenter un menu simplifié dans pcmanfm me parassait une bonne solution, puisque toute nouvelle installation pouvait se retrouver instantanément dans ce menu applications. Par contre, le grand nombre d'applications a forcément entrainé qu'on est sans cesse en train de personnaliser, d'où mon retour au handymenu.

Mais il faut fusionner, pas écraser, tant qu'à changer quelque chose, autant le faire bien.