Packaging

Les propositions de correctifs ou d'exercices pour Pyromaths.

Modérateur : Développeurs

Avatar de l’utilisateur
Yves
Messages : 465
Inscription : 21 janv. 2009, 20:40
Contact :

Re: Packaging

Message par Yves » 14 mai 2013, 10:52

djinn a écrit :Mon ancienne version d'OSX 10.7.3 a un environnement de développement cassé. Je n'arrivais pas à produire une appli 64 bits
Pour ce problème de traduction, une appli 32 bits devrait convenir ;) mais je je conçois bien que tu préfères te concentrer sur d'autres questions…

Les menus Fichier et Aide sont en français, pas de soucis.
D'après la doc de Qt:
QMenuBar on Mac OS X is a wrapper for using the system-wide menu bar…
Qt for Mac OS X also provides a menu bar merging feature to make QMenuBar conform more closely to accepted Mac OS X menu bar layout. The merging functionality is based on string matching the title of a QMenu entry.
Seul le menu de l'application, qu'on retrouve sur chaque application, avec les sous-menus suivants est en anglais:
  • About Pyromaths
  • Hide Pyromaths
  • Hide Others
  • Show All
  • Quit Pyromaths
Qt gère de manière automatique l'insertion de ces éléments. Le nom de l'application provient du fichier Info.plist. Si une entrée avec le string quit (ou exit) est trouvée, elle est fusionnée avec celle du menu de l'application, sinon elle est créée. De même, si le string About est trouvé, le menu À propos est déplacé dans le menu de l'application pour devenir About Pyromaths.

Le hack du fichier nib permet de traduire uniquement Masquer Pyromaths, Masquer les autres et Tout afficher qui sont issus directement de qt_menu.nib. Par contre, Quitter Pyromaths et À propos de Pyromaths sont insérés dans ce menu via le mécanisme de détection et de fusion de Qt et demeurent en anglais.

L'utilisation de QTranslator() permet la traduction de tous les éléments (et éventuellement pour des traductions dans d'autres langues) et me semble plus propre que le hack du fichier nib.

Avatar de l’utilisateur
Yves
Messages : 465
Inscription : 21 janv. 2009, 20:40
Contact :

Re: Packaging

Message par Yves » 14 mai 2013, 16:28

Le problème de traduction est résolu :D

J'ai refait les manipulations pour intégrer QTranslator() comme je l'avais décrit précédemment et le menu est en français ! :)

Et le menu Aide --> À propos est bien déplacé dans Pyromaths --> À propos de Pyromaths comme attendu sur OS X.

Avatar de l’utilisateur
djinn
Messages : 183
Inscription : 03 mars 2013, 10:38

Re: Packaging

Message par djinn » 14 mai 2013, 18:04

Bonne nouvelle! :)

J'ai peut-être une réserve quant à l'usage de QTranslator pour traduire l'ensemble de l'application: pour ce qui est de l'interface graphique Qt, pas de problème, j'imagine que c'est un bon choix; pour ce qui est du reste, je pense aux exercices TeX notamment, c'est plus problématique. Mettre des QStrings partout, ça risque d'être un peu lourd…

PS: En fait, c'est mon environnement de développement 32bits que j'ai cassé -- en essayant de lui faire avaler ton ditto -arch x86_64. :D

Avatar de l’utilisateur
Yves
Messages : 465
Inscription : 21 janv. 2009, 20:40
Contact :

Re: Packaging

Message par Yves » 14 mai 2013, 18:38

djinn a écrit :C'est plus motivant d'être deux sur un projet, même quand au final un seul fait l'essentiel du boulot. :)
C'est vrai, merci pour ton soutien qui m'a motivé à venir à bout de ce problème de traduction :)
djinn a écrit :J'ai peut-être une réserve quant à l'usage de QTranslator pour traduire l'ensemble de l'application: pour ce qui est de l'interface graphique Qt, pas de problème, j'imagine que c'est un bon choix; pour ce qui est du reste, je pense aux exercices TeX notamment, c'est plus problématique. Mettre des QStrings partout, ça risque d'être un peu lourd…
Effectivement.

J'ai commité les changements relatifs à cette traduction. Dans interface.py, j'ai rajouté
self.action_a_propos.setMenuRole(QtGui.QAction.AboutRole)
et dans pyromaths.py
# Intégration de QTranslator
from PyQt4.QtCore import QTranslator
translator = QTranslator()
translator.load("macmenu_fr", "data")
app.installTranslator(translator)
Je ne pense pas qu'il soit nécessaire de rajouter des conditions
if sys.platform != "darwin":
Mais il faudrait tester sur Windows et Linux pour s'assurer que tout fonctionne toujours correctement ;)

J'ai rajouté le fichier de traduction compilé macmenu_fr.qm dans data. N'hésite pas à le déplacer si tu penses qu'il serait mieux ailleurs (il faudra alors le signaler dans setup.py, pyromaths.py et Makefile).

Est-ce qu'on intègre le fichier de traduction macmenu_fr.ts non compilé quelque part ?
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE TS>
<TS version="2.0" language="fr">
<context>
    <name>MAC_APPLICATION_MENU</name>
    <message>
        <source>Hide %1</source>
        <translation>Masquer %1</translation>
    </message>
    <message>
        <source>Hide Others</source>
        <translation>Masquer les autres</translation>
    </message>
    <message>
        <source>Show All</source>
        <translation>Tout afficher</translation>
    </message>
    <message>
        <source>Quit %1</source>
        <translation>Quitter %1</translation>
    </message>
    <message>
        <source>About %1</source>
        <translation>À propos de %1</translation>
    </message>
</context>
</TS>
On pourrait même imaginer de compiler le .ts en .qm dans le Makefile avec la commande
lrelease macmenu_fr.ts
voire même d'écrire le .ts dans le Makefile avec la commande echo, mais, je ne suis pas sûr que ce soit d'un grand intérêt :roll:

Avatar de l’utilisateur
Yves
Messages : 465
Inscription : 21 janv. 2009, 20:40
Contact :

Re: Packaging

Message par Yves » 14 mai 2013, 19:05

djinn a écrit :C'est normal que tu aies du mal à saisir son utilité: dans le cas py2app elle est à peu près nulle.
$(clean) nettoie les sources en enlevant, outre les fichiers python compilés (*.pyc) et les backups (*~) qui pourraient traîner là, le fichier MANIFEST.in et le dossier egg-info créés lors du précédent build (lesquels décrivent les fichiers inclus lors du build), et un dossier BUILDIR, sous-dossier direct de BUILD nommé comme la cible $@ (à l'origine, plusieurs paquets étaient construits en copiant d'abord les sources dans un dossier destiné à héberger ensuite la construction; Désormais, ce n'est plus le cas que pour deb. Malgré tout, le mécanisme générique de nettoyage de ce sous-dossier a été maintenu dans la macro commune $(clean)). Or py2app n'utilise pas BUILDIR (il construit directement dans BUILD), ignore MANIFEST.in et n'utilise pas non plus egg-info semble-t-il.
Est-ce qu'on ne pourrait pas conférer une utilité à $(clean) sur Mac, c'est à dire qu'elle supprime build/lib, build/python2.*-standalone et dist/Pyromaths*.app ?

Avatar de l’utilisateur
djinn
Messages : 183
Inscription : 03 mars 2013, 10:38

Re: Packaging

Message par djinn » 14 mai 2013, 22:45

Yves a écrit :J'ai commité les changements relatifs à cette traduction.
(...)
Mais il faudrait tester sur Windows et Linux pour s'assurer que tout fonctionne toujours correctement ;)
Tout a l'air de fonctionner sous Linux. :)
Bon, comme j'utilise essentiellement pyromaths en mode ligne de commande d'habitude (en gros je n'utilise la GUI que pour vérifier que je n'ai rien cassé en chamboulant tout le source tree), j'ai peut-être raté quelque chose. :P
Yves a écrit :J'ai rajouté le fichier de traduction compilé macmenu_fr.qm dans data. N'hésite pas à le déplacer si tu penses qu'il serait mieux ailleurs.
Vu la structure actuelle des sources, je crois que c'est le bon endroit. :)
Quand on se lancera sérieusement dans la localisation (on a déjà toute la version espagnole, si j'ai bien suivi) il faudra probablement trouver un vrai nid à ces fichiers de traduction, mais pour l'instant…
Yves a écrit :Est-ce qu'on intègre le fichier de traduction macmenu_fr.ts non compilé quelque part ?
Oui, je pense que tout ce qui est nécessaire à générer toute partie du projet doit être intégré dans git. Or, il est fort probable qu'on doive régénérer le .qm à un moment dans le futur.
Reste à lui trouver une place -- ce qui relance le débat du nid des fichiers langues…
Yves a écrit :On pourrait même imaginer de compiler le .ts en .qm dans le Makefile
Je suis pour. :)
Je voudrais arriver à faire la même chose avec les "vignettes" d'exercice et le fichier *.py qui produit l'exercice correspondant…
Avec make tu peux t'en sortir avec une cible dans le genre:
*.qm:
    lrelease *.ts
…(si les fichiers qm et ts étaient dans le même dossier que Makefile) pour qu'un fichier qm soit régénéré automatiquement dès que son homologue ts a été modifié.
Bien entendu, il faut que que ta cible app dépende elle-même de ces fichiers qm pour qu'un make app déclenche la re-compilation des ts modifiés.
Yves a écrit :voire même d'écrire le .ts dans le Makefile avec la commande echo, mais, je ne suis pas sûr que ce soit d'un grand intérêt :roll:
Je ne crois pas non plus. En fait, je continue à me poser la même question pour les manifestes: ne seraient-ils pas mieux, finalement, en tant que vrais fichiers quelque part plutôt que "cachés" dans Makefile?
Une idée que j'aime bien c'est de maintenir l'interface setup.py fonctionnelle. C'est la raison pour laquelle j'étais pour l'intégration du "hack setenv" dans setup.py: le gars qui tente un ./setup.py py2app se retrouve avec quelque chose de fonctionnel. Peut-être pas optimal, mais fonctionnel. C'est un contrat qui coûte pas (encore) cher à honorer et qui, au final, rend les choses plus simples pour tout le monde (l'utilisateur s'y retrouve naturellement, et le développeur sait où mettre quoi).
En cachant les MANIFEST.in dans Makefile je rompt en quelque sorte ce pacte. Je l'ai fait parce que, de toute manière, l'existence de plusieurs MANIFEST.in que l'on doit copier à la main et renommer avant d'appeler setup.py, c'était déjà casser l'interface; Et puis la redondance entre manifestes fait que les choses sont plus claires quand on les construit de manière hiérarchique, comme c'est le cas actuellement, plutôt qu'en ayant 5 fichiers MANIFEST.in ne différant que subtilement de l'un à l'autre. Lesser of two evils… :|
Dernière modification par djinn le 14 mai 2013, 23:43, modifié 2 fois.

Avatar de l’utilisateur
Yves
Messages : 465
Inscription : 21 janv. 2009, 20:40
Contact :

Re: Packaging

Message par Yves » 14 mai 2013, 23:39

djinn a écrit :Tout a l'air de fonctionner sous Linux. :)
Bon, comme j'utilise essentiellement pyromaths en mode ligne de commande d'habitude (en gros je n'utilise la GUI que pour vérifier que je n'ai rien cassé en chamboulant tout le source tree), j'ai peut-être raté quelque chose. :P
Merci pour tes tests :)

Je pensais supprimer le qm, le remplacer par le ts et régénérer le qm à chaque make avec la commande:
cd $(PYRO)/data && lrelease macmenu_fr.ts
mais ta suggestion me semble plus appropriée. Si j'ai bien compris, on garde à la fois le ts et le qm ce qui nous laisse un setup.py toujours fonctionnel.
djinn a écrit :il faudra probablement trouver un vrai nid à ces fichiers de traduction
data/translations ?

Je découvre la syntaxe de Makefile; comment on adapte ce code si ts et qm sont dans un dossier data/translations ?
*.qm:
    lrelease *.ts

Avatar de l’utilisateur
djinn
Messages : 183
Inscription : 03 mars 2013, 10:38

Re: Packaging

Message par djinn » 15 mai 2013, 10:26

Yves a écrit :Si j'ai bien compris, on garde à la fois le ts et le qm ce qui nous laisse un setup.py toujours fonctionnel.
C'est ça. :)
Yves a écrit :data/translations ?
Par exemple. Quelques remarques:
  • Si on peut trouver plus court que translations (peut-être lang, locale…), ça serait pas plus mal. Il faudrait voir si une norme se dégage d'autres projets similaires (même s'il ne s'agit que d'un nom de dossier, autant ne pas réinventer la roue).
  • Je pense qu'un fichier langue n'est pas un data_file, mais un package_data (en langage distutils); Tout comme les vignettes d'exercice, d'ailleurs -- ce n'est probablement pas pour rien qu'ils ressortent tous deux dans le cadre du processus make. Auquel cas, sa place est dans les sources (src/), quelque part à côté des fichiers GUI qu'il traduit (peut-être dans un sous-dossier?).
  • Si on maintient malgré tout les qm dans data/, au moins temporairement (le temps que le tri data_files/package_data soit effectué), les ts au moins (qui ne sont jamais distribués) devraient probablement être situés ailleurs dans l'arborescence.
Yves a écrit :Je découvre la syntaxe de Makefile; comment on adapte ce code si ts et qm sont dans un dossier data/translations ?
Disclaimer: j'ai déjà bossé quelque fois avec make, mais avec tellement de temps entre chaque épisode que je suis contraint de le réapprendre à chaque fois. D'ailleurs, je me suis trompé sur le caractère wildcard de make dans l'exemple précédent; Et j'ai dû me frapper de la doc pour essayer de répondre à cette question! :)
En supposant que les ts sont dans locale/ et que les qm vont dans data/, peut-être quelque chose dans ce genre:
data/%.qm: locale/%.ts
    lrelease $< -qm $@
$< serait remplacé par le chemin du fichier ts considéré et $@ par celui de son homologue qm.
Et, du côté de la cible app, rajouter la dépendance sur ce qm:
app: version data/macmenu_fr.qm
    # Make standalone Mac application
    $(clean)

Avatar de l’utilisateur
Yves
Messages : 465
Inscription : 21 janv. 2009, 20:40
Contact :

Re: Packaging

Message par Yves » 15 mai 2013, 18:47

Pour l'instant, j'ai laissé les fichiers ts et qm dans data, pas motivé par la syntaxe de Makefile ;)

J'ai rajouté la traduction de Choose, Save et Cancel qui apparaissent dans les boîtes de dialogue. J'ai renommé le fichier de traduction qtmac_fr.ts.

J'ai trouvé de nouveaux fichiers superflus dans Pyromaths.app/Contents/Resources/lib/python2.7/site-packages.zip. Comme les fichiers sont dans une archive zip, il faut les supprimer via l'option excludes de setup.py et j'ai aussi rajouté les fichiers so à exclure puisque de toute façon setup.py n'est plus franchement minimaliste et que c'est bien le rôle de l'option excludes.

J'ai commité les changements.

Avatar de l’utilisateur
Yves
Messages : 465
Inscription : 21 janv. 2009, 20:40
Contact :

Re: Packaging

Message par Yves » 16 mai 2013, 13:31

djinn a écrit :j'en suis arrivé à un point intéressant sur pack. Pour aller vite: je crois qu'on peut tester intensivement et envisager l'intégration dans develop.
Je pense que tu peux intégrer pack dans develop :)

Avatar de l’utilisateur
djinn
Messages : 183
Inscription : 03 mars 2013, 10:38

Re: Packaging

Message par djinn » 19 mai 2013, 11:34

Bon travail. :)
Je suis d'accord avec toi: setup.py est bien le bon endroit pour exclure tout ça.

J'ai testé et inclus la règle make pour traduire automatiquement les fichiers data/*.ts modifiés. La cible app ne dépend pour l'instant que du fichier data/qtmac_fr.qm. Ça marche niquel. :)
Tu as enlevé le drapeau "exécutable" de setup.py dans le commit 85640311; J'imagine que c'est par erreur. Personnellement, en tous cas, je lance directement ./setup.py -- c'est plus rapide. Du coup, je l'ai à nouveau rendu exécutable. :P
Yves a écrit :Je pense que tu peux intégrer pack dans develop :)
Si personne ne s'y oppose, je merge…

Avatar de l’utilisateur
Jérôme
Administrateur - Site Admin
Messages : 1120
Inscription : 26 août 2006, 13:10
Localisation : Nantes
Contact :

Re: Packaging

Message par Jérôme » 19 mai 2013, 18:58

Si c'est fonctionnel, il est bien évident que tu peux effectuer un merge. Penses également à compléter le fichier README. Par ailleurs, il me semble qu'il y avait un soucis avec la création du RPM. As-tu regardé ce que ça donnait ?
Pyromaths génère des fiches d'exercices et leur corrigé en toute simplicité.
Un programme multi-plateformes libre et gratuit sous licence GPL

Avatar de l’utilisateur
djinn
Messages : 183
Inscription : 03 mars 2013, 10:38

Re: Packaging

Message par djinn » 20 mai 2013, 10:17

C'est fonctionnel autant que l'on a pu en juger avec Yves. Maintenant, il y a tellement de combinaisons possibles… En le mergeant, l'avantage c'est qu'on récupère plus de testeurs, et donc plus d'opportunités de mettre le doigt sur un problème caché.
Je ne me souviens pas de soucis avec les RPM, mais en tous cas il sont bien créés.
Que veux-tu que je j'ajoute au fichier README?

Avatar de l’utilisateur
Jérôme
Administrateur - Site Admin
Messages : 1120
Inscription : 26 août 2006, 13:10
Localisation : Nantes
Contact :

Re: Packaging

Message par Jérôme » 20 mai 2013, 10:26

Un petit résumé dans le style des autres pour dire ce que tu as fait dans la prochaine version de Pyromaths.
Pyromaths génère des fiches d'exercices et leur corrigé en toute simplicité.
Un programme multi-plateformes libre et gratuit sous licence GPL

Avatar de l’utilisateur
Yves
Messages : 465
Inscription : 21 janv. 2009, 20:40
Contact :

Re: Packaging

Message par Yves » 20 mai 2013, 10:28

En fait, c'est dans NEWS… ;)

Répondre