|
|
<chapter id="tdevelop-scripting">
|
|
|
|
|
|
<chapterinfo>
|
|
|
<authorgroup>
|
|
|
<author><firstname>Ian</firstname><surname>Geiser</surname></author>
|
|
|
<!-- ROLES_OF_TRANSLATORS -->
|
|
|
</authorgroup>
|
|
|
</chapterinfo>
|
|
|
|
|
|
<title>Utilisation des scripts dans KDevelop</title>
|
|
|
|
|
|
<sect1 id="running-scripts">
|
|
|
<title>Exécution de scripts</title>
|
|
|
<para>Pour accéder à un script disponible pour &tdevelop;, utilisez le menu <menuchoice><guimenu>Outils</guimenu><guimenuitem>Scripts</guimenuitem></menuchoice>. Si vous n'avez pas ce type d'élément de menu, c'est qu'il n'y a aucun script installé disponible pour KDevelop. </para>
|
|
|
</sect1>
|
|
|
|
|
|
<sect1 id="adding-scripts">
|
|
|
<title>Ajout de scripts</title>
|
|
|
<para>Une fois que vous avez ajouté la prise en charge de KScript à votre application hôte, l'ajout des scripts est tout aussi facile. Les scripts sont composés de deux parties, un fichier « desktop » qui contient des métadonnées sur le script et le script lui-même. Cette approche a été utilisée pour des raisons de sécurité et de simplicité. Le fichier « desktop » fournit des métainformations pour les menus et le type du script. Ce comportement évite à l'application hôte d'avoir à contrôler le chargement de chaque script. Voici un exemple de ce fichier : </para>
|
|
|
<para>L'exemple ci-dessus montre les parties principales que KScript cherchera. Le premier élément, le « Nom », est le nom qui apparaîtra à l'utilisateur dans l'application hôte et le « Commentaire » sera habituellement fourni sous la forme d'une infobulle. Le « Type » est le plus important, car il sert à sélectionner le moteur de script approprié pour lancer le script. Actuellement, les seuls disponibles pour KDE sont « ShellScript/bash » et « JavaScript/kjs ». L'étape suivante consiste à créer le script proprement dit. Pour l'exemple ci-dessus, le type de script employé est « ShellScript/bash ». Le moteur de script « shellscript » fournit quelques renseignements au développeur. Le premier élément est l'ID DCOP de l'application hôte, qui est passé au script comme premier argument. Cela signifie que n'importe où dans le script, la valeur de « $1 » retournera l'ID DCOP de l'hôte. Voici un exemple de script shell : </para>
|
|
|
|
|
|
<para>Ce script est tout à fait simple. Il exécute simplement une commande et positionne le texte du premier document sur la sortie de « ls -l »</para>
|
|
|
|
|
|
<para>Un des outils les plus utiles dans le développement de scripts pour des applications est l'application KDCOP.</para>
|
|
|
<figure id="screenshot-kdcop" float="1">
|
|
|
<title>KDCOP parcourant des interfaces DCOP dans &tdevelop;</title>
|
|
|
<mediaobject>
|
|
|
<imageobject><imagedata fileref="kdcop_browsing.png"/></imageobject>
|
|
|
</mediaobject>
|
|
|
</figure>
|
|
|
|
|
|
<para>L'outil KDCOP permet aux développeurs de scripts de parcourir et de déboguer les interfaces actuelles de l'application hôte. KDCOP offre également une possibilité intéressante aux utilisateurs de sélectionner une méthode et de faire glisser le code actuel sur leur éditeur de texte. Ce comportement facilite la vie des personnes qui ne sont pas expertes avec les méthodes DCOP du langage hôte. Actuellement, KDCOP prend en charge KJSEmbed, Python et la méthode de shell UNIX pour accéder à DCOP.</para>
|
|
|
|
|
|
<para>Une fois que le script est achevé, il est prêt à être installé. Les développeurs d'applications devront documenter l'endroit où rechercher les scripts. Dans le cas de l'exemple ci-dessus pour Kate, les scripts se trouvent dans « $TDEDIRS/share/apps/kate/scripts ».</para>
|
|
|
|
|
|
<figure id="screenshot-scripts" float="1">
|
|
|
<title>Scripts &tdevelop; sur le système de fichiers</title>
|
|
|
<mediaobject>
|
|
|
<imageobject><imagedata fileref="script_location.png"/></imageobject>
|
|
|
</mediaobject>
|
|
|
</figure>
|
|
|
|
|
|
<para>Le fichier de script « desktop » et son script associé devraient se trouver dans le même dossier. Pour les développeurs de scripts, il est également recommandé que toutes les autres ressources de scripts, telles que les fichiers d'interface graphique ou les fichiers de données, résident aussi dans le dossier du script. Dans l'exemple ci-dessus, le script apparaîtra sous le menu Outils->Scripts KDE. Autre chose importante à noter pour les développeurs, les scripts ne devraient pas effectuer d'opérations susceptibles de provoquer un long blocage ou de conduire à une boucle d'événement (eventloop). C'est parce que la version actuelle de l'interface de script est adaptée pour les tâches automatisées qui s'exécutent jusqu'à leur aboutissement. Ce problème est en cours de correction et d'extension pour KDE4. </para>
|
|
|
|
|
|
</sect1>
|
|
|
|
|
|
|
|
|
</chapter>
|
