Clone
3
api_reference FR
ispyisail edited this page 2026-09-12 08:09:09 +12:00

Automatiser QElectroTech

Comment piloter QET depuis d'autres programmes, et à quoi ressemblent les fichiers XML.

Correction, septembre 2026. Les versions précédentes de cette page affirmaient que QElectroTech prend en charge les scripts Python et un système de greffons, et indiquaient aux lecteurs d'installer des greffons dans ~/.local/share/QElectroTech/plugins/ et équivalents. Rien de tout cela n'existe. Il n'y a ni interpréteur embarqué, ni interface de greffon, ni répertoire de greffons — QET ne lit jamais ces chemins. La page ci-dessous décrit ce qui existe réellement, et ce n'est pas rien ; ce n'est simplement pas cela.

Ce que QET offre réellement :

Une ligne de commande sans interface 13 verbes qui ouvrent un projet et l'exportent, l'inspectent ou le réécrivent sans interface graphique. La véritable surface d'automatisation.
Des fichiers XML .qet et .elmt sont du XML ordinaire, lisible et modifiable par n'importe quel outil.
Un programme compagnon externe qet_tb_generator, lancé depuis une entrée de menu.
Le code source C++ Pour qui construit QET lui-même, ou un fork.

Ce qu'il n'offre pas : des scripts embarqués dans quelque langage que ce soit, une API de greffons, un répertoire de modules chargeables, ou une interface d'automatisation vers une instance en cours d'exécution.


1. La ligne de commande

C'est ce que la plupart des automatisations devraient utiliser. Un indicateur d'export reconnu est détecté avant le démarrage de l'interface : le processus s'exécute sans affichage, fait le travail et se termine — il n'ouvre pas de fenêtre et ne transmet rien à une instance déjà lancée.

qelectrotech --export-pdf monprojet.qet sortie.pdf

Les arguments sont positionnels, pas --option=valeur. La forme est toujours qelectrotech <indicateur> <projet.qet> <sortie>, avec les deux exceptions signalées plus bas.

Les verbes

Indicateur Sortie Remarques
--export-pdf un PDF tous les folios, une page chacun
--export-png un répertoire un NN_Titre.png par folio
--export-svg un répertoire un NN_Titre.svg par folio
--export-bom CSV nomenclature, depuis la base de données du projet — la même source que l'export de l'interface
--export-wiring CSV liste de câblage de-à, une ligne par conducteur — équivaut au menu Projet → Liste de câblage (base de données) / Exporter le plan de câblage
--export-cables CSV la même liste logique, construite depuis le XML du document
--export-wires CSV numéros de conducteurs — équivaut au menu Projet → Exporter la liste des noms de conducteurs
--export-nets CSV réseaux électriques — bornes groupées en potentiels
--export-links CSV renvois de folio, signalant maîtres et esclaves sans lien
--info JSON relevé structurel : comptes d'éléments et de conducteurs par folio, bornes non connectées. Écrit sur stdout si aucun chemin n'est donné
--resave .qet charge le projet et réécrit son XML
--set-titleblock .qet renseigne des champs de cartouche, puis enregistre
--check-elements rapport valide des fichiers .elmt — prend un fichier ou un répertoire, pas un projet

Deux commutateurs supplémentaires :

  • --show-terminals — dessine les marqueurs et noms de bornes dans les sorties PDF/PNG/SVG. Désactivé par défaut, conformément au dialogue d'export de l'interface. Utile pour repérer visuellement une broche non connectée.
  • --set-titleblock accepte des affectations clé=valeur après le chemin de sortie : date=today ou une date ISO AAAA-MM-JJ, les clés standard de cartouche, ou toute autre clé, enregistrée comme champ personnalisé. Une affectation incorrecte échoue avant toute écriture.

Codes de retour

0 succès · 1 le travail a échoué (projet illisible, rien à exporter, fichier non inscriptible) · 2 erreur d'appel (argument manquant, affectation incorrecte). Cela rend l'outil directement utilisable dans une chaîne d'intégration continue.

Bon à savoir

  • --export-cables et --export-wiring doivent concorder. L'un est construit depuis le XML du document, l'autre depuis la base de données du projet. Lancer les deux et les comparer vérifie directement que la base décrit toujours le projet — ce qui n'est autrement observable que via l'interface.
  • Prévoyez toujours un délai d'expiration dans vos scripts. Un projet enregistré par une version antérieure déclenche un avertissement au chargement ; en mode ligne de commande les boîtes de dialogue sont répondues automatiquement, mais une fenêtre modale imprévue reste la façon classique de bloquer indéfiniment une exécution sans interface.
  • Les sauvegardes de récupération après plantage sont volontairement désactivées en mode ligne de commande : leur écriture en arrière-plan entre en concurrence avec la fin du processus.
  • QT_QPA_PLATFORM=offscreen suffit pour ces verbes. Xvfb n'est pas nécessaire.
  • C'est aussi la vraie réponse de QET à « imprimer des étiquettes de fils ». QET n'a pas d'imprimante intégrée de repères de fils/manchons (voir la section Impression des diagrammes du manuel utilisateur pour ce que l'impression couvre réellement). Le flux documenté sur le forum consiste à exporter ce CSV et à l'introduire dans le logiciel propre d'une imprimante d'étiquettes — Brady, WAGO Smart-Printer et les outils Phoenix Contact acceptent tous le CSV directement. Une limite connue, signalée par un tableautier sur le forum : l'export sort une ligne par conducteur sans consolidation de quantité, donc N étiquettes identiques sortent comme N lignes dupliquées plutôt qu'une ligne avec une colonne quantité — prévoyez de dédoublonner dans un tableur avant d'imprimer un grand lot. Les imprimantes de type Cembre nécessitant un fichier .FNR ou une colonne de code support ne sont pas produites par cet export du tout ; cette correspondance doit être construite à la main depuis le CSV.

Exemple : une chaîne de révision

set -e
qelectrotech --set-titleblock in.qet estampille.qet indexrev=C date=today
qelectrotech --export-pdf estampille.qet "release/rev-C.pdf"
qelectrotech --export-bom estampille.qet "release/rev-C-bom.csv"

Voir aussi la Référence ligne de commande.


2. Lire et écrire les fichiers directement

.qet et .elmt sont du XML. Tout ce qui sait analyser du XML peut les traiter — xml.etree de Python, lxml, xmlstarlet, XSLT, à votre convenance. C'est ce que les gens veulent dire lorsqu'ils parlent de « scripter QET » : le script est un programme à vous, qui lit et écrit les fichiers, et qui s'exécute à côté de QET, non à l'intérieur.

Un vrai squelette .qet

<project title="ArduinoLCD" version="0.80">
    <properties>
        <property show="1" name="saveddate">17/04/2021</property>
    </properties>
    <newdiagrams>
        <border rows="8" cols="17" rowsize="80" colsize="60" .../>
        <inset folio="%id/%total" author="" title="" .../>
        <conductors type="multi" .../>
        <report label="%f-%l%c"/>
        <xrefs>
            <xref type="coil" master_label="%f-%l%c" slave_label="(%f-%l%c)" .../>
        </xrefs>
    </newdiagrams>
    <diagram title="LCD 4 DATA" order="1" folio="%id/%total" cols="11" rows="7" ...>
        <elements>
            <element x="390" y="570" z="10" orientation="0"
                     type="embed://import/oznaczenia/tekst_08.elmt"
                     uuid="{52d4b9e8-05c3-49a2-8455-a42ff651200a}"
                     prefix="" freezeLabel="false">
                ...
            </element>
        </elements>
        <conductors> ... </conductors>
    </diagram>
    <collection> ... </collection>
</project>

Les points qui font trébucher :

  • Il n'y a pas d'enveloppe <diagrams>. Les <diagram> sont des enfants directs de <project>, un par folio, ordonnés par leur attribut order.
  • <element> n'a pas d'id. Il est identifié par uuid, et son attribut type est un emplacement, généralement embed://… pour un élément copié dans la collection propre au projet.
  • <newdiagrams> contient les valeurs par défaut des nouveaux folios, pas les folios eux-mêmes.
  • Les définitions d'éléments du projet vivent sous <collection> : un projet est donc généralement autonome.

Référence complète : Project XML.

Un vrai squelette .elmt

<definition version="0.90" type="element" link_type="master"
            width="200" height="70" hotspot_x="100" hotspot_y="35">
    <uuid uuid="{2cbd2b72-1d04-f03d-758f-ce3a14dbb3c5}"/>
    <names>
        <name lang="en">UPS</name>
        <name lang="fr">UPS</name>
    </names>
    <kindInformations>
        <kindInformation name="type">coil</kindInformation>
    </kindInformations>
    <informations>Author: RDS for QelectroTech</informations>
    <description>
        <rect x="0" y="0" width="460" height="590" style="..."/>
        <terminal uuid="{73279019-…}" name="" x="-90" y="10" orientation="w" type="Generic"/>
    </description>
</definition>

Les points qui font trébucher :

  • width, height, hotspot_x, hotspot_y sont des attributs obligatoires de <definition>, et largeur/hauteur doivent être des multiples de 10 — sans quoi QET arrondit à la dizaine supérieure.
  • L'uuid est un attribut (<uuid uuid="{…}"/>), pas le texte de l'élément.
  • Les <name> sont par langue et exigent un attribut lang.
  • link_type est ce qui fait d'un élément un maître, un esclave ou un bornier — voir Lier des éléments.

Référence complète : Elements XML.

Validez ce que vous produisez

Rien ne contrôle un fichier écrit à la main avant que QET ne l'ouvre, mais la ligne de commande vérifie les fichiers d'éléments pour vous :

qelectrotech --check-elements mes_elements/

Chaque fichier est signalé OK, WARN (se charge mais suspect — par exemple zéro borne) ou FAIL (illisible, racine incorrecte, boîte englobante manquante), et le code de retour est non nul en cas d'échec. À mettre en intégration continue si vous générez des .elmt.

Règles empiriques

  • Fermez le projet dans QET avant de réécrire son fichier. QET détient son propre modèle en mémoire et vous écrasera à l'enregistrement.
  • --resave est un normaliseur bon marché : chargez, réécrivez, puis comparez, pour voir ce que QET réécrit silencieusement avant de fonder un outil sur une hypothèse de balisage.
  • L'identité des éléments et des conducteurs passe par l'UUID. Copier un nœud d'élément sans lui donner un nouvel uuid produit deux éléments que QET considère comme un seul.

3. qet_tb_generator — ce que « greffon » veut dire dans QET

Il existe une entrée de menu, Lancer le plugin de création de borniers, et un programme derrière elle. qet_tb_generator est un programme tiers distinct, distribué sur PyPI, qui lit et écrit des fichiers .qet depuis l'extérieur pour construire des borniers.

python -m pip install --upgrade qet_tb_generator

QET le lance en parcourant une liste fixe d'emplacements — QETApp::dataDir() + "/binary/", le répertoire courant, ~/.qet/, puis ce que résout le PATH — et en le démarrant comme un processus fils ordinaire. C'est là toute l'intégration : pas de mémoire partagée, pas d'API, pas de rappels. Si l'exécutable ne se trouve sur aucun de ces chemins, l'entrée de menu ne peut pas le trouver.

Le support communautaire se trouve sur le forum : Scripts · Code/Programmation

Écrire « un greffon » revient donc à écrire un programme autonome qui manipule les fichiers, exactement comme au §2. Il n'y a aucune interface à implémenter ni aucun répertoire où s'installer.


4. Le code source C++

Pour modifier QET lui-même, ou construire un fork :

Repères, tous dans sources/ :

Classe Fichier Rôle
QETProject qetproject.cpp un projet : folios, collection, chargement et enregistrement
Diagram diagram.cpp un folio (une QGraphicsScene)
Element qetgraphicsitem/element.cpp un symbole placé
Conductor qetgraphicsitem/conductor.cpp un conducteur
Terminal qetgraphicsitem/terminal.cpp un point de connexion
projectDataBase dataBase/projectdatabase.cpp le cache de requêtes — voir La base de données du projet

Attention à l'écart de vocabulaire : l'interface dit fil, page et symbole ; le code dit conductor, diagram et element. Chercher le mot de l'interface est la façon habituelle de conclure à tort qu'une chose n'est pas implémentée.


5. Ce qui n'existe pas

Dit clairement, puisque cette page affirmait le contraire :

Affirmation Réalité
Scripts Python embarqués Aucun interpréteur n'est lié ni chargé. Toute mention de Python dans le code est le lanceur de qet_tb_generator.
Un système / une interface de greffons Aucun QPluginLoader, aucune ABI de greffon, rien qui charge du code externe.
~/.local/share/QElectroTech/plugins/ et équivalents QET ne lit jamais ces chemins. Les créer ne fait rien.
Une API d'automatisation vers une instance en cours Aucune. SingleApplication transmet des arguments de fichiers à une instance lancée, c'est tout.

Savoir si QET doit se doter d'une interface de script est une question ouverte — voir les pages Vision et Feuille de route. Si cela arrive, cette page le dira quand ce sera réel, et pas avant.