Ici on n'a que votre IP, votre pseudo et votre adresse mail que nous ne traitons pas.
Quand vous êtes enregistrés, une seule requête permet de vous afficher les messages que vous n'avez pas lus.
Primtux8 est arrivée! Rendez-vous ici
Vous pouvez désormais vous inscrire librement en cliquant sur "S'enregistrer".

Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
Evolution des Handy-menu
#1
Liste des évolutions des Handy-menus à envisager :
  • des icônes sur les onglets
  • un fichier de configuration facilement éditable (pour les handymenus, c'est impossible à ouvrir en texte)
  • un outil de configuration plus convivial

Avant de me lancer à tête perdu, je vais analyser ce que propose le projet 3hg-menu qui a l'air d'être une amélioration notable des handy-menu.
Répondre
#2
Alors, je donne quelques pistes de réflexion :

* l'ajout d'icône sur les onglets est assez compliqué en l'état. Je m'explique : l'interface est généré via un fichier .glade : facile à éditer avec le concepteur d'interface de glade mais ne permet pas à ma connaissance d'ajouter un icône dans un onglet. (mais j'aimerais avoir tord)
Le soucis reste identique pour 3hg-menu.
L'API de GTK permet de passer cette limitation mais ça demande de réécrire l'interface en python avec l'API GTK... pas une mince affaire.
* Pour le fichier de configuration : vous faites comment actuellement ? Vous n'éditez que à partir de l'outil de config ?
Quel format vous parait le plus adapté : conf, yaml, json, toml.
* outil de config plus convivial : quel est le soucis principal
Répondre
#3
Pour moi le souci majeur est celui-ci:

- Si une application ou une icône manque, le handymenu refuse de démarrer, et comme on ne peut pas éditer le fichier de configuration, on ne peut corriger le problème qu'en la lançant via le terminal, et ça pour un novice c'est pas top, ils devraient pouvoir démarrer même si une application est indisponible et afficher un message indiquant une erreur si elle n'est pas trouvée au moment où on clique dessus. Aussi, celui qui veut éditer manuellement devrait pouvoir le faire. Pour le format peu importe, du moment qu'il s'ouvre en texte.

Il y en a d'autres:

- Le changement d'icône est trop fastidieux: on ne voit pas les miniatures (et je ne me rappelle plus si c'était comme ça sous xfce) et ça ne s'ouvre pas directement vers /usr/share/pixmaps).
- La présentation des applications en mode édition est en colonne, y aurait-il moyen de l'avoir en tableau, comme les handymenus?
Répondre
#4
Rappel moi, Steph sur quel source je dois m'appuyer : directement celles des sources Primtux ou les sources des handymenu (dans ce dernier cas, quel version) ?
Je suis un peu perdu avec les versions et mon comparatif des sources me laisse perplexe : il a été adapté à Primtux ?
Répondre
#5
Oui on l'a modifié. Il faut utiliser notre version. On n'a pas utilisé les sources on a directement modifié les fichiers. Ce sont les handymenus primtux2, prends les i386.
Répondre
#6
Steph a écrit :Oui on l'a modifié. Il faut utiliser notre version. On n'a pas utilisé les sources on a directement modifié les fichiers. Ce sont les handymenus primtux2, prends les i386.

Ok, (oui, de toute façon, c'est du python donc compatible pour toute les archis) j'ai fait un correctif rapide sur le refus de démarrage lié à l'accès à l'icône.
Voici à quoi ça ressemble : https://framapic.org/gallery#tX46G6G99ls...PQHddM.png

Est-ce que ça te parait correct ou faut-t-il envisager un icône de substitution ?
Répondre
#7
Ça me va très bien du moment que l'application démarre et qu'on peut ajouter une icône via la configuration.
Répondre
#8
Alors, j'ai effectué 2 changements notables (pour l'instant que sur la version maxi mais ça devrait être identique sur les 2 autres) :

1. Le handymenu démarre même si les applications n'ont plus d'icône est le clic sur ces applis inopérentes n'ont aucun effet. (ça ne ferme pas le handymenu même si l'option et activé)
2. la config est désormais stocké dans un fichier yaml (et non plus dans un fichier binaire avec pickle) et l'édition de ce fichier va mettre à jour le menu du handymenu.
Attention, ce n'est pas du live : si l'on édites le fichier pendant que le handymenu est ouvert, il ne se passe rien : il faut le relancer.

En revanche, je ne sais pas ou mettre les sources modifiés ?
Répondre
#9
Ben dis donc! Tu peux les zipper et les envoyer par mail? tu veux les mettre sur le git (le nôtre ou le tien d'ailleurs)?
Répondre
#10
Bon, j'ai tout mis ici : https://github.com/mothsART/handymenu-primtux
C'est peut-être temporaire. (à déterminer).

J'ai essayé de faire les choses bien avec des commits unitaires (chaque correctif bien cloisonné).

On peut désormais lancer le soft en local pour effectuer des correctifs. (ça me simplifie drôlement)

Le fait que le code des 4 handymenu soient à peut de chose prêt identiques nécessiterais une bonne factorisation.

Maintenant que le fichier de config est en yaml, je pense réfléchir à éditer le fichier de config par défaut. En effet, cette config lancé au premier démarrage est codé en dur et nécessiterais d'être dans un fichier à part)
Répondre
#11
Tu fais comme tu le sens, par contre j'aimerais changer l'emplacement du fichier de configuration: il est dans le ./home actuellement et en théorie on ne doit pas y écrire avec un .deb, donc il serait dans un répertoire du style /usr/share/handyconfig-maxi... Il faudrait aussi qu'il soit remplaçable par un autre paquet (à savoir celui des logiciels supplémentaires) => je ne l’intégrerai donc pas aux paquets des handymenus, il sera directement dans les répertoires de manière à pouvoir être mis à jour par les paquets de logiciels supplémentaires.
Répondre
#12
il faudrait en revanche que j'intègre la partie source (répertoire Debian avec tout ce que ça comporte) dans le dépôt, non ?
Répondre
#13
Mon dernier commit https://github.com/mothsART/handymenu-pr...94a926b927 change le fichier de config de place.
Répondre
#14
mothsart a écrit :il faudrait en revanche que j'intègre la partie source (répertoire Debian avec tout ce que ça comporte) dans le dépôt, non ?

- Si tu parles des fichiers qui sont sur le git, est-ce que tu es inscrit ici? https://framagit.org => sinon tu t'inscris et j'ouvre un projet handymenu et tu clones ton git.

- Si tu parles des sources des paquets, je n'ai pas de dépôts src.

- Si tu parles de l'intégration des paquets dans les dépôts PrimTux j'aime franchement mieux le faire, je m'y retrouve.

De toute façon il va falloir les tester.

Si je regarde les fichiers, où sera placé le handymenu.default.yaml et comment sera-t-il remplacé par celui de config qui sera dans un autre répertoire?
Répondre
#15
Steph a écrit :- Si tu parles des fichiers qui sont sur le git, est-ce que tu es inscrit ici? https://framagit.org => sinon tu t'inscris et j'ouvre un projet handymenu et tu clones ton git.

Oui, j'ai un compte frama.

Steph a écrit :- Si tu parles des sources des paquets, je n'ai pas de dépôts src.

Oui, je parlais des fichiers control, rules, *.install etc qui permette de générer le .deb.
Je veux pas forcément faire le taf à ta place mais vérifier que c'était bien synchrone.

Steph a écrit :Si je regarde les fichiers, où sera placé le handymenu.default.yaml et comment sera-t-il remplacé par celui de config qui sera dans un autre répertoire?

Oui, au même endroit :
/usr/share/handyconfig-primtux/handymenu.yaml
/usr/share/handyconfig-primtux/handymenu.default.yaml

Par contre viens de m'apercevoir d'un truc : la config en dur (qui va être remplacé par le fichier default) vient écraser le fichier de config si elle ne fonctionne pas correctement. (ex: fichier yaml mal formé)
Il faut absolument que je change ce fonctionnement.
Je vais tenter d'avertir l'utilisateur avec un message (zone de warning) lorsque l'on arrive pas à charger le fichier de config.
Répondre
#16
Y a-t-il un intérêt à compiler à partir des sources quand les fichiers ne changent pas? Je veux dire qu'un .py en restera un, et à part tout mettre dans les bons répertoires, je n'en vois pas l'intérêt. Pour les handymenus je compile à partir de l'arborescence des fichiers par exemple.

J'en reviens aux fichiers de configuration: pour que le fichier handymenu.default.yaml soit remplacé (je parle pour mini, super, maxi), il faut qu'il porte le même nom, non? Sinon il fait comment pour gérer 2 fichiers de configuration: handymenu.default.yaml et handymenu.yaml?
Répondre
#17
https://framagit.org/Steph/handymenu-primtux
Répondre
#18
Donc là après test du handymenu-maxi:
- Ça démarre!
- C'est vraiment mieux de tout voir en texte.
- Attention, dépendance à ajouter: python-yaml
- La modification de la configuration s'enregistre bien mais dans le fichier handymenu.yaml qui doit être placé dans le répertoire /usr/share/handymenu-maxi, c'est donc ce fichier qui est pris en compte et non celui qui est dans /usr/share/handyconfig-maxi => c'est gênant => à la limite on peut ne pas inclure le répertoire /usr/share/handyconfig-maxi dans le paquet des handymenus et l'intégrer directement dans l'iso mais il faut que ce soit celui-ci qui soit modifié et pris en compte.
Répondre
#19
Au niveau des fichiers de configuration des handymenus, ne serait-il pas plus logique d'avoir le comportement suivant:
  • un fichier /home/01-mini/.handymenu.config.yami, /home/02-super/.handymenu.config.yami, /home/03-maxi/.handymenu.config.yami, ... (en fait un fichier dans le home de celui qui crée ou modifie une configuration de handymenu pour sa session ou une session spécifique) qui est pris en priorité s'il existe;
  • un fichier /usr/share/handyconfig-primtux/handymenu.default.yaml qui est une configuration par défaut prise en compte lorsque n'existe pas un fichier de configuration dans le home de l'utilisateur
?
Répondre
#20
Steph a écrit :Tu fais comme tu le sens, par contre j'aimerais changer l'emplacement du fichier de configuration: il est dans le ./home actuellement et en théorie on ne doit pas y écrire avec un .deb, donc il serait dans un répertoire du style /usr/share/handyconfig-maxi... Il faudrait aussi qu'il soit remplaçable par un autre paquet (à savoir celui des logiciels supplémentaires) => je ne l’intégrerai donc pas aux paquets des handymenus, il sera directement dans les répertoires de manière à pouvoir être mis à jour par les paquets de logiciels supplémentaires.

La mise à jour des fichiers de configuration est faite avec les paquets de logiciels supplémentaires et on ne doit normalement pas écrire dans les /home avec des deb, qui sont à mon sens la meilleure manière de mettre à jour vers les logiciels supplémentaires.
Répondre
#21
Steph a écrit :La mise à jour des fichiers de configuration est faite avec les paquets de logiciels supplémentaires et on ne doit normalement pas écrire dans les /home avec des deb, qui sont à mon sens la meilleure manière de mettre à jour vers les logiciels supplémentaires.

Ce que je proposais ne tient donc pas, sauf à faire un niveau intermédiaire, des /usr/share/handyconfig-primtux/handymenu.01-mini.yaml, /usr/share/handyconfig-primtux/handymenu.02-super.yaml etc. . Ainsi il resterait toujours la possibilité à un utilisateur de personnaliser ses handymenus sans que sa configuration ne soit écrasée par une mise à jour.
Répondre
#22
Steph a écrit :Y a-t-il un intérêt à compiler à partir des sources...
Je suis dac avec toi sur la théorie. Mais je ne sais pas comment faire de .deb sans les outils traditionnels de debian : dh_make, debuild etc.

Pour ce qui est des fichiers de config.
La règle stricte dans les distrib linux :
- la config dans le /~ ne s'écrase jamais avec un deb, effectivement.
- La config dans son /~ doit être dans le dossier caché .config => /home/01-mini/.config/handymenu.yaml
- La config dans le ~/ est prioritaire (si elle existe) à celle dans /etc/handymenu-mini.yaml. (/etc centralise toutes les configs communes à tous les utilisateurs)

Dans voilà comment j'envisage les choses (ex pour l'utilisateur mini):

1. Si le handymenu trouve un fichier dans le /home/01-mini/.config/handymenu.yaml : il le charge et cette config ne sera pas impacté par une mise à jour.
(inconvénient : si l'on rajoute/edite/supprime dans une maj un nouveau soft, il faudra l'éditer à la main pour que ça soit pris en compte)
2. Si le handymenu ne trouve pas de fichier dans le /home ou que celui-ci est mal construit, alors on charge /etc/handymenu-mini.yaml
3. Si le handymenu dans /etc/handymenu-mini.yaml est mal construit, alors on lance /etc/handymenu-mini.default.yaml
+ on affiche un message d'avertissement. (prévenir l'admin que quelque chose cloche)
Le fichier par défaut représente un filet de sécurité : on garde un soft opérationnel quoi qu'il arrive.

Pour la configuration, on suit la même logique :

Si l'on trouve un fichier /home/01-mini/.config/handymenu.yaml, c'est celui-ci que l'on édite, sinon on édite /etc/handymenu-mini/handymenu.yaml
Le fichier default est une confi en dur : l'éditer c'est prendre le risque d'un soft non conforme aux attentes.
Je pourrais pousser le vice en affichant un message si le md5 n'est pas conforme. (l'idée est de simplifier l'assistance)
Répondre
#23
Steph a écrit :Attention, dépendance à ajouter: python-yaml

Oui, bien vu. J'ai oublié de le signaler vu que ma bécane de dev est blindé de dépendances python.

J'oubliais, j'ai effectué 2 correctifs :
- pour que le sélecteur d'icône ouvre directement /usr/share/pixmaps
- pour que l'édition d'un lanceur affiche l'icône : voir imprim écran :
[Image: 6a816420fccc4364c2b1eee43aa9dc56.png]

Sur cette capture, on voit clairement que l'i18n ne c'est pas activé : pas d’inquiétude, j'ai pas pris le temps de bien la gérer en mode DEBUG.
Répondre
#24
Très bien l'histoire de l'icône.
Mais passer par une édition c'est trop long pour l'utilisateur, le fichier de configuration doit pouvoir être écrasé par un paquet, l'édition étant une bonne solution de secours au cas où un problème survient. Alors donc pourquoi ne pas mettre le fichier de configuration par défaut dans /etc et écraser ce fichier lors de l'installation des non-libres? Ce premier fichier sera directement intégré dans l'arborescence à la compilation de l'iso.
Pour empaqueter j'utilise debreate qui prend tout bêtement en compte l'arborescence que tu as construite.
Répondre
#25
Pas de prob Steph, ça me simplifie les choses.
Répondre


Atteindre :


Utilisateur(s) parcourant ce sujet : 7 visiteur(s)