Evolution des Handy-menu

[Steph]

J'aime quand on me dit ça ^.^

[ideefixe]

Le projet est-il d'intégrer ces nouveaux HandyMenus à la version de PrimTux3 du printemps 2018 ?

[Steph]

Pourquoi on s'en passerait?

[ideefixe]

Edit the launcher, change the label seront-ils tranduis en français ?

[mothsart]

Steph : j'ai mergé mes correctifs sur framagit.
Le dernier commit est assez important : j'ai fait une grosse factorisation suivi d'un refactoring. La factorisation c'est pour me simplifier la vie : marre de corriger un truc puis copié/collé au bon endroit x 3.
Le refactoring c'est pour gagner un peu de place et par conséquent alléger le paquet.

Derrière, il y a toute la gestion des chemins de config évoqués précédemment et de gros pans de correctifs sur la gestion des erreurs en cas de fichier inexistant, non autorisé, ma formé etc.

J'ai pris du temps à tout re-tester mais j'ai peut-être quelques oublis.
Je vais me concentrer désormais sur le dernier point :

- La présentation des applications en mode édition est en colonne, y aurait-il moyen de l'avoir en tableau, comme les handymenus?

Ideefixe : vu ton imprim écran, c'est un soucis de locale : rien n'est traduit. (ou presque rien)
C'est que l'applicatif ne trouve pas le dossier des locales. A voir sur mes dernières modifs si le soucis persiste.

[Steph]

Ok merci ! Je regarde ça quand je peux!

[ideefixe]

Est-ce que leur apparence va changer ou bien sera-t-elle semblable à http://wiki.primtux.fr/doku.php/handymenu-primtux3

[Steph]

oui

[mothsart]

Alors, suite à nos échanges mails, j'ai fait pas mal de correctifs.
Pour pouvoir reproduire, j'ai préféré refaire un paquet debian : j'ai mis les sources (principalement le debian/handymenu.install) dans le dépôt.
A toi de les utiliser ou non, Steph.

Je crée d'abord handymenu_1.0.orig.tar.gz à partir du dossier source puis je lance :

Code :

dpkg-buildpackage -us -uc

pour obtenir le paquet .deb.

Je pense avoir résolu les principaux soucis lié :
1. accès aux pixmaps
2. l'icône de configuration ne doit pas apparaître que dans la session prof, pour les 3 autres, ont doit permettre la coche pour fermer ou pas le handymenu après exécution d'une application.
3. Enregistrement des fichiers yaml après édition des menus

Néanmoins, l'utilisateur prof doit avoir les droits d'écritures sur le dossier etc/handymenu

[ideefixe]

Bonjour, lorsque le code sera validé et intégré dans PrimTux3, est-ce que les sources de ce nouveau HandyMenu seront publiques sur Framagit ?

[mothsart]

Mais elles sont publiques, non ? https://framagit.org/Steph/handymenu-primtux

[mothsart]

Bon, j'ai identifiés d'autres bugs dans la config (principalement issu de mon refactoring (A) ).
J'ai corrigé dans la foulée.
J'ai réédité le fichier debian/handymenu.install pour que le fichier .mo de traduction soit au bon endroit.
Enfin, j'ai identifié une dépendance obligatoire : rox-filer

[Steph]

Oui rox-filer qui ouvre le répertoire des .desktop si on ne trouve pas le raccourci dans le menu.

[Steph]

Bon ça avance:
- Les modifications sont effectives en maxi, mini, super
- Mais c'est en anglais
- Si je ne mets pas les yaml dans les répertoires des handymenus il ne va pas les chercher dans /etc
- la coche qui permet de fermer après exécution d'un programme devrait à mon sens rester dans le ~ de l'utilisateur, car si on n'est pas sudo ça ne fonctionne pas.
- Idem pour la configuration du handymenu-prof: l'ouvrir sans sudo ne permet pas de modifier.

[mothsart]

- Mais c'est en anglais

Y'a bien le fichier handymenu.mo dans /usr/share/locale/fr/ ?
Si oui, c'est sans doute lié au comportement décrit ci-dessous.

- Si je ne mets pas les yaml dans les répertoires des handymenus il ne va pas les chercher dans /etc

En fait, le mode DEBUG est pour l'instant plus ou moins du bricolage :
Si il ne trouve pas /etc/handymenu/handymenu-xxx/handymenu-xxx.default.yaml (ou qu'il n'a pas les droits de lecture : ce qui me semble ête le cas) alors, il en déduit qu'il est en mode DEBUG et cherche tout selon l'arbo des sources.

- la coche qui permet de fermer après exécution d'un programme devrait à mon sens rester dans le ~ de l'utilisateur, car si on n'est pas sudo ça ne fonctionne pas.

Très pertinent : je vais corriger dans ce sens.

- Idem pour la configuration du handymenu-prof: l'ouvrir sans sudo ne permet pas de modifier.

C'est que l'utilisateur prof n'a pas les droits sur l'emplacement du fichier de conf.
(C'est, je pense pour cette raison, qu'à l'origine c'est enregistré dans l'espace utilisateur.)
Il faut que l'utilisateur prof ai les droits de lecture et d'écriture dans le dossier /etc/handymenu/

Le plus propre est d'attribuer le dossier au groupe (ça dans le fichier preinst) et que l'utilisateur prof face parti de ce groupe. (je dirais par défaut dans la distrib avec dans le fichier preinst : une verif si non présent, on le rajoute => pour tout ceux qui font la maj)

[mothsart]

- la coche qui permet de fermer après exécution d'un programme devrait à mon sens rester dans le ~ de l'utilisateur, car si on n'est pas sudo ça ne fonctionne pas.

J'ai fait un commit dans ce sens : ça enregistre désormais dans /home/xxx/.config/handymenu-xxx-noclose.conf

Dans le même commit : quand il ne trouve pas le fichier de config par défaut, il affiche explicitement qu'il est en mode DEBUG dans la console. (ça devrait nous aider dans nos échanges futures)

[mothsart]

Je viens de merger un commit ou la structure du menu dans la config est strictement identique à l'applicatif.
On s'approche du but

[mothsart]

Pour l'histoire des droits, ce script (handymenu.postinst) devrait être suffisant :

Code :

#!/bin/sh

set -e

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

[Steph]

Allez ça vient, encore un petit effort...
Donc:
- les fichiers en /etc => ok
- c'est en français
- la grille en configuration en tableau au lieu du vertical => très bien
Mais...
- la coche de fermeture fonctionne quand on est administrateur et ne fonctionne pas pour les sessions élèves (quand je coche et que je suis mini, le handymenu ne se ferme pas au lancement d'une application).
- Dans la configuration, monter et descendre une section ne fonctionnent pas.
- Peux-tu allonger le nombre de caractères utilisables pour une section?

[mothsart]

Allez ça vient, encore un petit effort...
Donc:
- les fichiers en /etc => ok
- c'est en français
- la grille en configuration en tableau au lieu du vertical => très bien
Mais...

Ah, ça fait plaisir d'avoir passé l'ensemble de ces verrous.

Je regarde pour le reste.

[mothsart]

- la coche de fermeture fonctionne quand on est administrateur et ne fonctionne pas pour les sessions élèves (quand je coche et que je suis mini, le handymenu ne se ferme pas au lancement d'une application).
- Dans la configuration, monter et descendre une section ne fonctionnent pas.

C'est bon, reproduit et résolu.
Pour les boutons monter et descendre la section, je me suis permis de rajouter les icônes de flèche orienté vers le haut et bas.

[mothsart]

- Peux-tu allonger le nombre de caractères utilisables pour une section?

La config précédente était de 12 caractères par onglet peut importe la taille du texte. (conséquence du tronquage)
J'ai mis indéfini : ce qui laisse supposer que l'onglet prend la taille du texte.

Pour des questions d’esthétiques, on peut faire quelque chose du genre : taille de 12 caractères si le texte est <= à une taille de 12.
Mais ça me semble inutile.

A part cette question, je pense qu'on est pas loin de la vérité pour les handymenus !

[Steph]

En fait ça ne fonctionne pas car compilation-jeux dans mini est coupé. Ça ne devait pas être 12 mais 16.

[mothsart]

Oui, j'ai compris ce qui n'allais pas.
Mon correctif permet n'importe quelle taille, l'onglet s'adapte à la taille du texte.
Est-ce que ça convient ? (Mettre une taille fixe plus haute va juste décaler le soucis)

[Steph]

oui ça devrait.