1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<title>FAQ - Scripteur</title>
</head>
<body>
<h2>FAQ - Scripteur</h2>
<p>Auteur : Craig Ringer</p>
<dl>
<h3>Comment puis-je utiliser du texte non-ASCII dans le scripteur?</h3>
<p>Premièrement, assurez-vous que votre script possède une ligne
"coding" appropriée. Votre
script doit démarrer de la façon suivante :
<pre>
#!/usr/bin/env python
# -*- coding: latin-1 -*-
</pre>
ou
<pre>
#!/usr/bin/env python
# -*- coding: utf-8 -*-
</pre>
ou
<pre>
#!/usr/bin/env python
# -*- coding: ascii -*-
</pre>
</p>
<p>Ces lignes <b>doivent</b> être les deux premières de votre
script. Le "coding" <b>doit</b> correspondre à l'encodage actuel du
fichier.</p>
<p>Pour déterminer l'encodage du texte dans vim, tapez
<code> :set fileencoding?<enter></code>
La manière de déterminer l'encodage du texte variera pour d'autres
éditeurs, cela peut correspondre à votre langage. La commande
<code>file</code> n'est <i>pas</i> une méthode fiable pour déterminer
l'encodage d'un fichier.</p>
<p>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".</p>
<p>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 :
<code> UnicodeDecodeError: 'ASCII' codec can't decode byte 0xc3
in position 1: ordinal not in range(128)</code>
ce qui est évidemment loin d'être utile.</p>
<p>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.</p>
<h3>Quelle est la bonne structure à utiliser pour mes scripts?</h3>
<p>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.</p>
<h3>Pourquoi Python?</h3>
<p>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.</p>
<p>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. </p>
<p>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.</p>
<p>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.
</p>
<h3>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 ?</h3>
<p>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.
<p>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.</p>
<p>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.</p>
<p>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.</p>
<h3>Devrais-je utiliser 'from scribus import *' ou 'import
scribus'?</h3>
<p>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
<a href="http://effbot.org/zone/import-confusion.htm" title="Lien
externe">http://effbot.org/zone/import-confusion.htm</a>.</p>
<p>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.</p>
<h3>Que dire d'un style de programmation général ? </h3>
<p>De manière générale, nous nous en remettons aux gourous Python. Jetez un
coup d'oeil sur
<a href="http://www.python.org/peps/pep-0008.html" title="Lien
externe">http://www.python.org/peps/pep-0008.html</a> pour obtenir une analyse
plus complète du sujet.</p>
<p>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.</p>
<p>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.
</p>
<h3>Y a-t-il des particularités que je devrais connaître dans l'interface Python de
Scribus ?</h3>
<p>Oui, il y a quelques différences dont vous devriez être conscient :</p>
<ul>
<li>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.
</li>
<li>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.</li>
<li>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.
<br>
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.</li>
<li>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.</li>
</ul>
<h3>Puis-je utiliser le reste de la librairie standard de Python ou
des modules d'extension ?</h3>
<p>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.</p>
<h3>J'aimerais étendre Scribus en utilisant Python, et pas
seulement l'utiliser pour automatiser les opérations...</h3>
<p>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.
</p>
<h3>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.
</h3>
<p><b>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.</b> 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.</p>
<p>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.</p>
<h3>Donc... puis-je inclure des scripts dans des documents ou des modèles ?</h3>
<p>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.</p>
<h3>Qu'en est-il des scripts de démarrage ou déclenchés
par des événements ?</h3>
<p>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. <b>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.</b>.
<p>Le niveau de sécurité de Scribus sur un script au
démarrage est identique à celui du shell (par exemple <code>bash</code>),
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 <i>peut</i> 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.</p>
<p><b>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. </b>C'est une règle d'or
en sécurité informatique qui s'applique à tout programme et à tout
système d'exploitation.</p>
<h3>Et les extensions C++ pour Scribus ? Sont-elles sécuritaires ?</h3>
<p>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.</p>
<h3>Je ne sais pas comment obtenir <i>quelque chose</i>
à partir de Python, mais l'application principale Scribus le
supporte. Que dois-je faire ?</h3>
<p>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. </p>
<p>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. </p>
<h3>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 ?</h3>
<p>Vous avez plusieurs options :</p>
<ul>
<li>Patientez un peu, puis reposez votre question. </li>
<li>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.</li>
<li>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.</li>
<li>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.
</li>
</ul>
</body>
</html>
|
