FAQ - Scripteur

Auteur : Craig Ringer

Comment puis-je utiliser du texte non-ASCII dans le scripteur?

Premièrement, assurez-vous que votre script possède une ligne "coding" appropriée. Votre script doit démarrer de la façon suivante :

    #!/usr/bin/env python
    # -*- coding: latin-1 -*-

    #!/usr/bin/env python
    # -*- coding: utf-8 -*-

    #!/usr/bin/env python
    # -*- coding: ascii -*-

Ces lignes doivent être les deux premières de votre script. Le "coding" doit correspondre à l'encodage actuel du fichier.

Pour déterminer l'encodage du texte dans vim, tapez :set fileencoding? La manière de déterminer l'encodage du texte variera pour d'autres éditeurs, cela peut correspondre à votre langage. La commande file n'est pas une méthode fiable pour déterminer l'encodage d'un fichier.

Vous pouvez convertir l'encodage de fichiers avec l'utilitaire 'iconv', mais vous en aurez rarement besoin, étant donné que Python peut manipuler presque tous les encodages de texte s'ils sont indiqués dans la ligne "coding".

Quelques fonctions du scripteur demande du texte ASCII pur, et n'acceptent pas de texte unicode ou latin-1. Si vous appelez une de ces fonctions avec du texte non-ASCII, vous obtiendrez une erreur du type suivant : UnicodeDecodeError: 'ASCII' codec can't decode byte 0xc3 in position 1: ordinal not in range(128) ce qui est évidemment loin d'être utile.

Il semble par ailleurs y avoir un bug avec le modificateur de chaînes de caractères u'' dans la console de script. Ce problème a aussi été repéré dans l'interpréteur interactif de Python dans la ligne de commande. Il n'affecte pas les fichiers script. Jusqu'à ce que ce soit résolu, utilisez le constructeur Unicode ("mystring") ou utilisez des chaînes brutes (qui peuvent contenir du texte Unicode) à partir de la console de script.

Quelle est la bonne structure à utiliser pour mes scripts?

Commencez avec 'boilerplate.py' dans le répertoire samples. Ce script désactive les rafraîchissements (pour la vitesse) et contient un code qui assure leur réactivation, effectue des vérifications et retourne une erreur explicite en cas de démarrage hors de Scribus, etc.

Pourquoi Python?

Ce langage convient bien à l'intégration d'applications tout en restant complet et puissant. Il est aussi accessible aux nouveaux utilisateurs et bien documenté. De plus, il offre un support robuste pour le texte Unicode.

Python est un bon langage de liaison entre différents programmes et composants. Par exemple, pour permettre l'utilisation de votre base de données d'articles maison avec Scribus, l'interface Python constitue le moyen d'implantation le plus rapide et le plus simple.

Par ailleurs, il est facile d'écrire du code Python ordonné, que les autres personnes peuvent lire et comprendre. Si le script d'une autre personne ne fait pas exactement ce dont vous avez besoin, vous avez plus de chances de pouvoir l'adapter.

Comme l'inclusion de Python dans des applications pose certains problèmes particuliers, pour une pure automatisation scriptée, il vaut mieux utiliser un langage comme Qt Script for Applications ou lua. Mais pour aller au-delà de la simple automatisation, Python semble offrir la meilleure approche.

Je veux fournir une IU plus complexe que celle fournie par les dialogues inclus dans l'interface d'écriture des scripts. Comment puis-je le faire ?

Pour la plupart des tâches d'écriture de scripts, jusqu'à présent, la construction d'une IU simple dans Tkinter est un de vos meilleurs choix. Si vous désirez enrichir l'IU ou fournir des palettes avec lesquelles l'utilisateur peut travailler, tout en restant à l'intérieur de Scribus, vous devrez envisager d'écrire une 'extension de script' avec PyQt.

Dans la plupart des cas, il est recommandé de choisir Tkinter. C'est la seule trousse à outils pour IU qui fonctionne de manière fiable dans les scripts Scribus ordinaires, en raison de la façon dont ils sont exécutés dans les sous-interpréteurs. Il s'agit d'un progiciel presque universel des distributions Linux, bien qu'il ne soit pas installé par défaut, et il est hautement portable. Les utilisateurs peuvent être rebutés par l'aspect visuel de Tkinter, mais il fonctionne bien.

Si vous voulez écrire des IU plus avancées, le meilleur choix est PyQt. Vous pouvez écrire vos propres boîtes de dialogue et palettes à l'aide de PyQt, en conservant la possibilité d'enrichir l'interface de Scribus juqu'à un certain point. PyQt ne fonctionnera pas de manière fiable à partir d'un script ordinaire, mais il fonctionne bien à partir de scripts qui démarrent à l'aide de l'élément de menu "Load Extension Script...". Consultez la section avancée du manuel du scripteur pour obtenir plus de détails à ce sujet.

Les problèmes d'intégration de boucle et d'initialisation dans les sous-interpréteurs signifient que PyGtk et wxPython ne sont pas recommandés pour l'instant, et qu'ils ne fonctionneront probablement pas correctement. Étant donné que Tkinter fonctionne bien pour des scripts normaux, et PyQt pour des tâches plus avancées, il ne s'agit pas d'un problème majeur.

Devrais-je utiliser 'from scribus import *' ou 'import scribus'?

De manière générale, 'import scribus' est préférable. 'from ... import' peut amener de la confusion dans des boucles d'importation, en rechargeant des modules et dans certaines autres circonstances. Plus d'information http://effbot.org/zone/import-confusion.htm.

Même si 'import scribus' donne un code plus bavard, cela en vaut généralement la peine puisque le code devient alors lisible et explicite.

Que dire d'un style de programmation général ?

De manière générale, nous nous en remettons aux gourous Python. Jetez un coup d'oeil sur http://www.python.org/peps/pep-0008.html pour obtenir une analyse plus complète du sujet.

On fait une exception pour l'encodage du code source, où sont recommandés les eoncodages ASCII avec caractères d'échappement, latin-1 ou utf-8. N'importe lequel de ces encodages devrait bien fonctionner.

Veuillez noter qu'aucune règle n'est absolue : vous pouvez coder comme vous le désirez. Ces recommandations sont néanmoins justifiées, et vous avez intérêt à les suivre.

Y a-t-il des particularités que je devrais connaître dans l'interface Python de Scribus ?

Oui, il y a quelques différences dont vous devriez être conscient :

Les scripts Python démarrés dans Scribus ne peuvent pas créer de threads. Qt, la trousse à outils livrée avec Scribus, fournit son propre environnement de gestion des threads qui ne fonctionne pas bien avec celui de Python. Une interface vers QThread pourrait être fournie si le besoin était justifié et si la fonctionnalité pouvait être réalisée.
Pour le moment, PyQt n'est pas compatible avec les scripts Python lancés à partir de scripts Scribus normaux, même s'il peut maintenant être exploité à partir du mode 'extension de script'. Veuillez vous manifester sur la liste de diffusion si vous croyez être en mesure de contribuer à une solution. Pour ce faire, il vous faudra de l'expérience avec l'API Python/C, avec les sous-interpréteurs et avec PyQt.
L'extension Python de Scribus change l'encodage par défaut des chaînes de Python (sysdefaultencoding) pour utf-8. Par défaut, Python utilise l'ASCII. Parce que utf-8 est une (vaste) généralisation de l'ASCII, ceci ne devrait pas affecter les scripts qui utilisent seulement des chaînes encodées en ASCII. Les fonctions Scribus ont été testées et fonctionnent correctement pour du texte Unicode, donc il ne devrait pas y avoir de problème à cet égard.
Quoi qu'il en soit, il est possible que des modules d'extension en C d'un tiers posent des problèmes, si l'auteur n'a pas tenu compte de l'encodage du texte entrant. Ces problèmes sont presque toujours des bogues qui doivent être signalés à l'auteur du module, et ils devraient être rares. Si vous rencontrez un de ces problèmes, signalez-le sur la liste de diffusion ou sur IRC.
Python démarre à l'intérieur de Scribus. Il est possible de charger certains modules d'extension en C qui effectuent des tâches complexes d'initialisation qui peuvent perturber Scribus ou l'interpréteur Python. Si vous rencontrez un de ces modules, reportez-le sur la liste de diffusion ou sur IRC. Tout élément qui tente de démarrer sa propre boucle d'événements risque de faillir, et les interfaces vers les trousses à outils IU semblent aussi poser des problèmes. Tout ce qui génère des peut threads peut aussi causer des problèmes.

Puis-je utiliser le reste de la librairie standard de Python ou des modules d'extension ?

Oui, absolument. Scribus n'impose aucune restriction sur l'accès au reste de Python (sauf les limitations techniques décrites plus haut), et c'est un des éléments qui rend le scripteur si puissant. Il est possible que certaines fonctions Python comme la gestion des threads puissent être affectées par la manière dont l'interpréteur est incorporé, mais la plupart devraient être utilisable comme d'habitude.

J'aimerais étendre Scribus en utilisant Python, et pas seulement l'utiliser pour automatiser les opérations...

Présentement, c'est impossible. Des travaux sont en cours pour permettre d'enrichir Scribus à l'aide de Python, jusqu'à un certain point, spécialement en ce qui conerne l'IU. Il est maintenant possible d'utiliser PyQt pour écrire vos propres palettes, mais vous ne pourrez pas utiliser des objets Scribus personnalisés ni pénétrer dans les rouages de l'application. Le coeur de Scribus n'est malheureusement pas bien adapté à l'extension à partir de Python. Il vaut mieux recourir à C++ pour créer des extensions plus évoluées ou plus étroitement intégrées.

Qu'en est-il de la sécurité ? Suis-je assuré que les scripts ne détruiront pas mes données ou ne corrompront pas mon système d'exploitation.

Non. Ne lancez pas un script qui ne provient pas d'une source sûre et, de préférence, lisez-le au préalable. Le mauvais côté de la puissance de l'interface de script de Python est qu'il n'impose presque aucune restriction de sécurité. Tout ce que vous pouvez faire à partir d'un shell sans mot de passe, un script peut le faire aussi.

Si Python obtenait un support pour une exécution en environnement restreint comme c'était le cas dans les versions < 2.2, ce support pourrait être ajouté, mais présentement il n'y a aucune restriction. Il serait intéressant de repérer un langage de macro simple pour l'automatisation qui pourrait être inclus dans Scribus, mais présentement nous manquons de ressources pour ce faire.

Donc... puis-je inclure des scripts dans des documents ou des modèles ?

Non, voir ci-dessus. Nous ne pouvons pas fournir un environnement d'exécution restreint, donc il n'est pas sécuritaire de laisser des scripts voyager avec des documents. Sinon un script malicieux pourrait utiliser un document comme vecteur d'infection d'autres système. Vous souvenez-vous des virus macro de Word ? Oui. Nous aussi.

Qu'en est-il des scripts de démarrage ou déclenchés par des événements ?

Les scripts de démarrage sont supportés. Quant aux scripts qui démarrent moyennant la survenance d'un événement donné, ils pourraient être supportés dans l'avenir. Si un script est en position d'"infecter" un script de démarrage ou votre application, il est également capable de modifier votre .bashrc ou votre script de démarrage X. En d'autres mots, si vous décidez d'exécuter du code douteux sur votre machine, il est trop tard ! L'insertion éventuelle dans un script de démarrage de Scribus serait alors le moindre de vos soucis. Cette constatation n'est pas propre à Scribus et vaut pour les scripts bash, les programmes normaux et la plupart des extensions également. Souvenez-vous : n'exécutez pas de scripts qui ne proviennent pas de sources de confiance, car les scripts sont des programmes comme tous ceux que vous pourriez vouloir exécuter sur votre ordinateur..

Le niveau de sécurité de Scribus sur un script au démarrage est identique à celui du shell (par exemple bash), ou de votre système graphique d'authentification. Scribus ne peut pas vous protéger si vous décidez d'exécuter des programmes non fiables sur votre système. Il peut cependant éviter de fournir un support pour la propagation du code malicieux. C'est pourquoi Scribus supporte les scripts de démarrage (mais ils ne sont pas exécutés par défaut), tandis que les scripts ne peuvent pas être inclus dans les documents ou exécutés à partir de ceux-ci.

N'exécutez pas un programme, un script ou une extension, quels qu'en soient le type ou la provenance, à moins d'avoir vérifié que le programme est valide. C'est une règle d'or en sécurité informatique qui s'applique à tout programme et à tout système d'exploitation.

Et les extensions C++ pour Scribus ? Sont-elles sécuritaires ?

Pas du tout. Une extension C++ de Scribus peut faire presque tout ce qu'un autre programme sur votre ordinateur pourrait faire, donc ne la téléchargez que si vous avez absolument confiance en son auteur. Ceci est vrai pour les extensions de la plupart des programmes, puisqu'il est très difficile de restreindre l'effet d'une extension écrite en C/C++ peut faire.

Je ne sais pas comment obtenir quelque chose à partir de Python, mais l'application principale Scribus le supporte. Que dois-je faire ?

L'interface d'écriture des scripts requiert actuellement que chaque fonction soit écrite à la main - aucun mécanisme de génération ou d'encapsulage automatique de code n'est prévu. Cela s'explique en partie par l'absence d'API publique stable sous-jacente.

En général, si une fonction n'existe pas, c'est parce que personne n'a encore trouvé le temps ni éprouvé le besoin de l'écrire. Parfois, la fonction est plus compliquée qu'elle n'apparaît et peut nécessiter beaucoup de travail. Parfois, il s'agit d'un effort de cinq minutes. Posez la question poliment sur IRC ou sur la liste de diffusion; si quelqu'un a le temps et l'envie de faire le boulot, vous pourriez obtenir votre fonction.

J'ai posé la question sur la liste de diffusion ou sur IRC, mais personne n'a offert d'écrire cette fonction dont j'ai besoin pour le scripteur. Que puis-je faire ?

Vous avez plusieurs options :

Patientez un peu, puis reposez votre question.
Vous pouvez peut-être ajouter vous-même votre fonction - il y a des chances pour que quelqu'un qui travaille sur le scripteur puisse vous donner une idée de la quantité de travail nécessaire. En général, le scripteur n'est pas très compliqué et plusieurs fonctions sont triviales, donc même si vous ne connaissez pas beaucoup C++ vous ne devriez pas renoncer à entreprendre le travail. Quand j'ai commencé à travailler sur le scripteur, je ne connaissais absolument rien en C ou C++ ... Je désirais juste _vraiment_ quelques nouvelles possibilités.
Si vous décidez d'ajouter une fonction vous-même, rappelez-vous que tous les textes ne sont pas de l'ASCII. Utilisez le format 'es' dans PyArg_ParseTuple, plutôt que le format 's', et spécifiez un encodage "utf-8". Utilisez les méthodes QString::fromUtf8 et QString::utf8() pour les entrées et les sorties, respectivement, des objets QString. Jetez un coup d'oeil sur quelques uns des code du scripteur pour voir comment ils sont bâtis ou n'hésitez pas à vous adresser à IRC ou à la liste de diffusion si vous avez des problèmes.
Offrez de payer quelqu'un pour le faire. Cette approche vaut seulement dans le cas d'un grand projet qui requiert beaucoup de temps et d'efforts (et d'argent), mais c'est une option intéressant si vous avez vraiment besoin d'une fonction précise.