Topic: Utilisation de QET pour schémas PID

Bonjour,
J'essaye QElectrotech pour réaliser des schémas PID pour l'industrie chimique.
Ce n'est pas son usage dédié mais j'apprécie ses capacités :
- notion de projet avec un ensemble de folios,
- génération d'une nomenclature globale,
- connexions auto entre éléments,
- collections d'éléments,...

Mais je détourne l'usage des conducteurs pour en faire des tuyauteries.

Est-ce envisageable d'avoir d'autres types de connecteurs pour les éléments ?

Pour une vanne à commande pneumatique par exemple : connexions hydrauliques au procédé, connexions pneumatiques à l'électro-distributeur.
J'aimerais aussi récupérer la liste des tuyauteries que j'ai repéré.

Je ne suis pas développeur mais je peux aider, par exemple à fournir des éléments conformes aux normes ISO10628.

Re: Utilisation de QET pour schémas PID

Bonjour Opus,

Opus wrote:

Ce n'est pas son usage dédié mais j'apprécie ses capacités

Je crois que tu n'es pas le premier à faire cela nomicons/smile
Pour mon travail, je dessine aussi avec QET des plans pneumatiques et hydrauliques directement intégrés dans la documentation électrotechnique de machines CNC.

Opus wrote:

Est-ce envisageable d'avoir d'autres types de connecteurs pour les éléments ?

Non, un conducteur est un conducteur ! QElectroTech ne fait pas la différence entre un conducteur électrique et un tuyau pneumatique ou une conduite hydraulique.
Mais tu peux changer leur apparence en double-cliquant dessus et en allant dans l'onglet "apparence".

Dans la même fenêtre "propriétés des conducteurs", tu peux aussi détourner les champs "fonction" et "tension/protocole" pour entrer des informations que tu pourras utiliser dans les flèches de revoie.
Voir ici pour la mise en place :
https://www.youtube.com/watch?v=xoRwsC17nlo

Opus wrote:

J'aimerais aussi récupérer la liste des tuyauteries que j'ai repéré.

Pour l'instant, QET n'a pas encore de fonction intégrée qui réalise cela. Et les électriciens en auraient bien besoin aussi !
Malgré tout, nous savons que la faisabilité technique existe déjà car ces informations sont disponibles dans ton projet *.qet sous format xml.
Pour importer ces infos dans un tableur, il faudrait passer par un filtre XSLT qui convertirait le xml écrit par QET en du xml compréhensible par le tableur.
Si tu as envie de t'y mettre, voir ces quelques adresses :
http://www.w3schools.com/xsl/default.asp
http://www.zvon.org/comp/r/tut-XSLT_1.html
https://help.libreoffice.org/Common/Cre … ML_Filters

Opus wrote:

Je ne suis pas développeur mais je peux aider, par exemple à fournir des éléments conformes aux normes ISO10628

Les éléments de bonne qualité réalisés avec soin sont toujours les bienvenus nomicons/grin

Re: Utilisation de QET pour schémas PID

Nuri wrote:

Pour importer ces infos dans un tableur, il faudrait passer par un filtre XSLT qui convertirait le xml écrit par QET en du xml compréhensible par le tableur.

Merci pour les infos.
J'ai réussi un premier test : transformer un fichier .qet en une liste de conducteurs au format HTML.

Re: Utilisation de QET pour schémas PID

Super nomicons/happy !

T'as utilisé quoi ? Un filtre XSLT ?

Re: Utilisation de QET pour schémas PID

Oui un filtre XSLT, très basique.

Re: Utilisation de QET pour schémas PID

C'est une première : à ma connaissance, tu es le premier à réaliser cela, bravo !
Personnellement, j'ai jamais pris le temps, ni eu la patience, de m'intéresser en profondeur au sujet des filtres XSLT.
A l'occasion, est-ce que tu pourras nous montrer les résultats obtenus ? Sur le forum, ou par mail si les données sont sensibles.
Ces filtres ont le gros avantage de permettre d'exploiter plus de données issues de QET. C'est donc un sujet qui pourrait intéresser beaucoup d'utilisateurs.

Re: Utilisation de QET pour schémas PID

Oui, on en avaient parlé ici et sans trop trouver non plus, justement on cherchaient une personne ayant des compétences en filtres XSLT :
SUGGESTION : éditer les données QET dans un tableur (on the fly)
https://qelectrotech.org/forum/viewtopi … 2963#p2963

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: Utilisation de QET pour schémas PID

Je n'ai aucune compétence particulière en filtre XSLT, désolé.
J'ai suivi les liens de Nuri + quelques recherches.
J'ai ouvert un fichier test.qet dans notepad++ (avec le plugin XML tools). Et grâce à un tuto j'ai créer un filtre XSLT que j'ai appliqué au fichier qet.
Rien de compliqué, je le partagerai dès que possible.
Pour l'édition "on the fly" c'est une autre affaire...

Re: Utilisation de QET pour schémas PID

Pas de compétences non plus dans ce domaine de mon coté, pas que ce soit insurmontable, ni que ce soit du langage d'extraterrestre  nomicons/alien  comme dirait Nuri, mais ça demande un temps certain que l'on n'a pas pour l’étudier, alors que certains manipulent ces filtres tous les jours.
Dans les liens de mon post, il y a quelques tutos pour LO, avec MSO il semble plus facile d'importer l'arbre XML et de créer ses propres filtres XSLT dessus et ensuite de travailler sur les attributs et chaines du XML ...

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

10 (edited by Nuri 2016-10-13 18:32:28)

Re: Utilisation de QET pour schémas PID

@ Opus
oublie l'édition tabulaire "on the fly", aujourd'hui il y a d'autres priorités pour le développement de QET.

Toutefois, la manipulation des filtres XSLT serait un grand plus car cela permettrait de modifier certaines valeurs dans un fichier *.qet de manière très ciblée et avec le confort d'un tableur.
Par exemple pour changer un cartouche dans tout un projet qui fait plus de 100 folios.
Ou alors pour renuméroter toute une série de composants ou des borniers complets...
Bref, pour faire de la manipulation de données à grande échelle.
Je sais qu'on peut aussi faire UNE PARTIE de ces tâches avec un éditeur xml et utilisant "chercher et remplacer" mais le risque d'écrabouiller des valeurs qui n'auraient pas du être changées est beaucoup plus grand. Et là, quand ca arrive, c'est la cata... faut sortir les fichiers sauvegardés de la semaine passée...

D'après ce que j'avais lu, il semblerai que Microsoft et son Excel soit plus avancé là-dedans que l'équipe des GNU/Stallmann avec LibreOffice.
Ca marche aussi avec LibreOffice mais la mise en place est moins "neuneu-compatible", si tu vois ce que je veux dire...

11 (edited by Opus 2016-10-16 07:33:29)

Re: Utilisation de QET pour schémas PID

Bonjour,
Après quelques recherches, j'ai quelques remarques sur la structure d'un fichier qet.
Un fichier qet est un fichier XML, mais :
  - un fichier qet n'a pas de prologue : <?xml version = "1.0" encoding="UTF-8" ?>
  - il n'y a pas de schéma XML associé permettant de valider un fichier qet
Si une autre application génère un fichier qet il faudrait pouvoir le valider.
On pourrait aussi séparer dans un autre fichier XML la partie information des éléments.

12 (edited by Nuri 2016-10-17 09:56:50)

Re: Utilisation de QET pour schémas PID

@ Opus

un fichier qet n'a pas de prologue : <?xml version = "1.0" encoding="UTF-8" ?>

je ne connais pas les raisons pour lesquelles cette information n'existe pas.
Je pense que cette décision a du être prise au tout début du développement de QET.

On pourrait aussi séparer dans un autre fichier XML la partie information des éléments.

Tu parles des informations qu'on rentre à la main dans le dock "propriétés des éléments" ?
Ou de la définition des éléments embarqués marquée par la balise <collection> dans le fichier *.qet ?

Personnellement, je trouve très bien que tout soit intégré dans un seul et même fichier car cela rend les projets facilement transportables d'un PC à l'autre sans aucune perte de donnée (ce qui n'est pas forcément le cas avec les alternatives commerciales de QET où il manque parfois la moitié des données quand le projet arrive chez le client nomicons/pinch nomicons/getlost ...).

Et peu importe que tu sois sous Windows, Linux ou Mac, ca marche sur tous les systèmes nomicons/cool

De plus, un fichier *.qet se compresse très bien, avec souvent des ratios supérieurs à 10, ce qui rend les projets légers et donc facile à envoyer par mail (ce qui n'est pas forcément le cas avec les alternatives commerciales de QET où l'envoi par cloud est quasi indispensable nomicons/angry ...)

La seule chose qui peut rendre un fichier *.qet énorme et indigeste, c'est l'intégration d'un grand nombre d'images (jpg, png...) car elles sont codées en base 64 dans le xml, ce qui n'est pas optimal.

nomicons/wassat après réflexion, je vois pas trop où tu veux en venir avec ta proposition de séparer les info éléments dans un autre fichier ?!?

Re: Utilisation de QET pour schémas PID

Nuri wrote:

Tu parles des informations qu'on rentre à la main dans le dock "propriétés des éléments" ?

Oui, celles-ci. Dans le fichier qet, c'est classé là :
/project/diagram/elements/element/elementInformations/
Je veux pouvoir éditer ces données sans toucher au reste.
Ces propriétés seraient gérées dans un tableur puis ré-injectées dans le fichier qet.
Je continue mon apprentissage de l'XML pour voir comment faire.
Pour l'histoire de séparer ces données, je pensais à une structure de fichier telle que MS Office, LibreOffice, FreeCAD... qui sont des fichiers ZIP avec à l'intérieur des fichiers XML, des répertoires, des images...
Au niveau poids de fichier, c'est plus léger car déjà compressé, et facilement éditable.

14 (edited by Nuri 2016-10-17 15:16:58)

Re: Utilisation de QET pour schémas PID

/project/diagram/elements/element/elementInformations/
Je veux pouvoir éditer ces données sans toucher au reste

Normalement, tu devrais pouvoir t'en sortir avec les filtres XSLT aussi bien pour lire que pour écrire. Mais comme j'écrivais déjà plus haut, je n'ai pas d'expérience à partager dans le domaine filtre XSLT.

En fait, tu aimerais écrire toutes les données d'article (fabricant, référence, etc...) dans un tableur puis les réinjecter dans QET, c'est ca ?
Pour ma part, j'ai aussi besoin de faire quelque chose de semblable. L'idée qui me semblait la plus facile est d'écrire directement ces informations dans le nom des éléments (comme décrit dans le tuto dont j'ai déjà fait référence dans un topic en anglais).
Certes la quantité d'information est assez limitée (on écrit toutes les données dans une ligne, séparées par des points-virgules) mais pour l'instant ca me suffit.
Quand j'ai fini mon projet, j'exporte la nomenclature en *.csv puis je la lie avec une macro Basic LibreOffice qui me converti ces données en tableaux *.elmt que je peux alors réinjecter dans mon projet.

Tu peux essayer d'adpater ce système à tes besoins. Il faudra alors vraisemblablement modifier le code de la macro Basic. Niveau difficulté, je pense que c'est comparable au bidouillage avec les filtres XSLT.
C'est-à-dire beaucoup plus facile que d'implémenter une nouvelle fonction en C++ dans les dizaines de milliers de lignes du code source de QET nomicons/tongue

Par ailleurs, je pense que la gestion des données d'article est un sujet majeur qui intéresse beaucoup de monde et qui propulserait QET définitivement au niveau de certains programmes commerciaux.
Si tu as d'autres idées, d'autres manières de faire (base de données ?) et d'autres points de vue, n'hésite pas à partager car nous manquons encore un peu d'expérience dans ce domaine.
En ligne de mire, il faut garder à l'esprit que ces fonctionnalités doivent être simples et relativement faciles à mettre en oeuvre car y'a pas une équipe de 12 développeurs C++ à temps plein derrière !

Pour l'histoire de séparer ces données, je pensais à une structure de fichier telle que MS Office, LibreOffice, FreeCAD... qui sont des fichiers ZIP avec à l'intérieur des fichiers XML, des répertoires, des images...
Au niveau poids de fichier, c'est plus léger car déjà compressé, et facilement éditable.

Joshua (le développeur principal) avait déjà parlé de mettre les images dans un sous-dossier et de transformer le format *.qet en une archive compressée.
Seulement voilà, c'est pas une modif faite en quelques heures de travail et, pour l'instant, il y a des choses plus importantes à finaliser dans le code source.

Re: Utilisation de QET pour schémas PID

Nuri wrote:

Joshua (le développeur principal) avait déjà parlé de mettre les images dans un sous-dossier et de transformer le format *.qet en une archive compressée.
Seulement voilà, c'est pas une modif faite en quelques heures de travail et, pour l'instant, il y a des choses plus importantes à finaliser dans le code source.

Non, ça pourrait être simple a faire avec les libraires de inqlude.org, mais le problème se pose pour les paquets Windows et mac ..

https://www.kdab.com/additional-qt-libr … t-project/

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: Utilisation de QET pour schémas PID

Bonjour,
connaissez-vous l'initiative DEXPI ?
C'est une initiative pour améliorer l'interopérabilité entre logiciels d'ingénierie, basé sur des efforts précédents (ISO 15926, XMpLant schema, Proteus schema, ...).
Leur site internet : http://www.dexpi.org/
Je vous laisse découvrir, je cite la partie qui m'intéresse le plus :
"Currently, the focus of the DEXPI initiative is the exchange of Piping and Instrumentation diagrams (P&IDs)."
Ils ont un github, où est présente la spécification
https://github.com/DEXPI/Specification/ … cification
Il y a aussi une partie "Test Cases" qui rassemble les différents cas testés entre logiciels, et les résultats en cours (AutoDesk, Aveva, Hexagon,...)

Je sais que QElectroTech n'est pas prévu pour ça à la base, mais je rêve d'un fork basé sur QElectrotech qui bousculerait ce classement. nomicons/smile

Re: Utilisation de QET pour schémas PID

Bonjour Opus,

Je découvre et je salue cette initiative d'interopérabilité entre logiciels d'ingénierie, merci pour l'info.

http://www.dexpi.org/wp-content/uploads … ortrag.pdf

https://github.com/DEXPI/Specification/ … %201.2.pdf

https://download.qelectrotech.org/qet/forum_img/DEXPI1.png
https://download.qelectrotech.org/qet/forum_img/DEXPI.png

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: Utilisation de QET pour schémas PID

Bonjour,

QET s'en sort très bien pour dessiner des schémas PID, ce que nous pouvons faire est d'ajouter de nouveaux champs informations dans l’éditeur de symboles et de schémas comme la capture plus haut, mais il en faudrait un nombre très conséquent d’après ce que j'en ai lu ...
Avec les textes dynamiques de la 0.7 il est possible d'automatiser le dessin et afficher les informations contenues dans le symbole ou dans le widget informations directement dans le schéma.

Par contre pour l'arbre XML et les différents attributs spécifiques ça se complique ...

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: Utilisation de QET pour schémas PID

Bonjour,

scorpio810 wrote:

QET s'en sort très bien pour dessiner des schémas PID, ...

Même si QET est capable de le faire j'ai peur que l'on ajoute une complexité non nécessaire à l'interface.
Généralement ce sont des métiers différents entre celui qui réalise les schémas P&ID et celui qui réalise les schémas électriques.
Avec l'architecture de QET, pourrais-t-on avoir une application schémas électriques et une autre pour les schémas P&ID ? Un peu comme le logiciel FreeCAD et ses différents ateliers ?

Concernant les symboles P&ID utilisé par DEXPI, il y a aussi un catalogue : http://tools.dexpi.org/symbolCatalogue/index.html
On peut trouver les symboles au format XML dans le github DEXPI (https://github.com/DEXPI/GraphicBuilder).

Re: Utilisation de QET pour schémas PID

Bonjour,

tu pourrais établir un cahier des charges sur les changements à effectuer dans le logiciel?
Dans le cas ou la seule solution possible serait de faire un fork, tu penses pouvoir trouver et rassembler une communauté de développeurs pour travailler sur ce projet, voir ajouter des nouveaux modules à QET ?

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

21 (edited by Opus 2018-07-18 03:09:03)

Re: Utilisation de QET pour schémas PID

scorpio810 wrote:

tu pourrais établir un cahier des charges sur les changements à effectuer dans le logiciel?

Cela doit être faisable, je vais y réfléchir.

scorpio810 wrote:

Dans le cas ou la seule solution possible serait de faire un fork, tu penses pouvoir trouver et rassembler une communauté de développeurs pour travailler sur ce projet, voir ajouter des nouveaux modules à QET ?

Franchement non, c'est pourquoi je dis que j'en rêve...

Concernant la communauté, je pensais à une synergie avec celle de FreeCAD où il y a régulièrement des demandes d'un module "conception d'usine".
Il y a une bonne initiative dans ce sens avec le module "flamingo" orienté tuyauteries et structure métallique.
Il y a même eu une demande pour faire un P&ID avec FreeCAD !
Il pourrait y avoir une passerelle entre QET et FreeCAD pour échanger les données du P&ID (fait dans QET) au modèle 3D (réalisé dans FreeCAD).

22 (edited by Nuri 2018-07-18 12:09:31)

Re: Utilisation de QET pour schémas PID

J'ai déjà utiliser FreeCAD à quelques occasions pour dessiner des pièces pour imprimantes 3D.
Il me semble que FreeCAD est également concu avec le Framework Qt ce qui pourrait faciliter une certaine interopérabilité avec QET.
Mais à moins de trouver une équipe motivée pour créer cette "passerelle", on risque de buter à nouveau sur le manque de ressources humaines...

Et c'est pas facile de rajouter énormément de propriétés aux éléments sans transformer le logiciel en usine à gaz.
On en bave déjà assez avec les propriétés électriques.
Peut-être qu'il serait plus ingénieux de lier QET à un système de base de données pour que chacun puisse rajouter des propriétés comme bon lui semble.
On manque un peu d'utilisateurs capables de faire des cahiers des charges assez développés pour que les développeurs de QET ne partent pas sur des fausses pistes.
Mon expérience personnelle se limite à la réalisation de schémas électriques. Le pneumatique, hydraulique et PID sont pour moi des sujets connexes avec lesquels je ne rentre pas dans le détail.

Re: Utilisation de QET pour schémas PID

Nuri wrote:

Il me semble que FreeCAD est également concu avec le Framework Qt

Oui, voir la page : https://www.freecadweb.org/wiki/Third_Party_Libraries, et si j'ai bien suivi la version en développement (0.18) supportera Qt5 / Python 3.

Et c'est pas facile de rajouter énormément de propriétés aux éléments sans transformer le logiciel en usine à gaz.

Bien d'accord, c'est ce qui me fait peur aussi.

Peut-être qu'il serait plus ingénieux de lier QET à un système de base de données pour que chacun puisse rajouter des propriétés comme bon lui semble.

Je ne sais pas pour l'architecture, mais il faudrait peut-être un jeu de propriétés par "métier".

Mon expérience personnelle se limite à la réalisation de schémas électriques. Le pneumatique, hydraulique et PID sont pour moi des sujets connexes avec lesquels je ne rentre pas dans le détail.

Pour moi c'est à peu près l'inverse : OK pour les P&ID, le reste je laisse faire les spécialistes.
Dans le "workflow" suivant, mon domaine de compétences s'arrête au point 3 :

  1. Réalisation du Schéma-bloc

  2. Puis du PFD

  3. et enfin des schémas P&ID

  4. Réalisation des schémas électriques par le partenaire électricien

Re: Utilisation de QET pour schémas PID

nuri wrote:

Et c'est pas facile de rajouter énormément de propriétés aux éléments sans transformer le logiciel en usine à gaz.

On en bave déjà assez avec les propriétés électriques.

Clair ! c'est 5 fichiers dans le code qui sont a modifier à chaque fois ne serai-ce que pour ajouter un nouveau champ information...

/trunk/sources/autoNum/assignvariables.cpp   
/trunk/sources/diagramcontext.h   
/trunk/sources/editor/ui/elementpropertieseditorwidget.cpp   
/trunk/sources/nomenclature.cpp   
/trunk/sources/qetapp.cpp



r5059-scorpio810.diff

Modified: trunk/sources/autoNum/assignvariables.cpp
===================================================================
--- trunk/sources/autoNum/assignvariables.cpp    2017-10-02 14:46:26 UTC (rev 5058)
+++ trunk/sources/autoNum/assignvariables.cpp    2017-10-02 16:59:53 UTC (rev 5059)
@@ -167,6 +167,7 @@
         QString str = formula;
         str.replace("%{label}", dc.value("label").toString());
         str.replace("%{comment}", dc.value("comment").toString());
+        str.replace("%{description}", dc.value("description").toString());
         str.replace("%{designation}", dc.value("designation").toString());
         str.replace("%{manufacturer}", dc.value("manufacturer").toString());
         str.replace("%{manufacturer-reference}", dc.value("manufacturer-reference").toString());
 
Modified: trunk/sources/diagramcontext.h
===================================================================
--- trunk/sources/diagramcontext.h    2017-10-02 14:46:26 UTC (rev 5058)
+++ trunk/sources/diagramcontext.h    2017-10-02 16:59:53 UTC (rev 5059)
@@ -34,6 +34,7 @@
  * label                          -> label or identification of element
  * formula                        -> formula used to create the label (formula is make with variable)
  * designation                    -> exhaustive comment used to explain what the element does.
+ * description                    -> exhaustive description used to explain what the element does.
  * comment                        -> a little comment wich can be displayed in the folio
  * manufacturer                   -> the manufacturer of the element
  * manufacturer-reference         -> the manufacturer reference of the element
 
Modified: trunk/sources/editor/ui/elementpropertieseditorwidget.cpp
===================================================================
--- trunk/sources/editor/ui/elementpropertieseditorwidget.cpp    2017-10-02 14:46:26 UTC (rev 5058)
+++ trunk/sources/editor/ui/elementpropertieseditorwidget.cpp    2017-10-02 16:59:53 UTC (rev 5059)
@@ -152,7 +152,7 @@
  */
void ElementPropertiesEditorWidget::populateTree()
{
-    QStringList keys{"label", "comment", "designation", "manufacturer", "manufacturer-reference", "machine-manufacturer-reference"};
+    QStringList keys{"label", "comment", "description", "designation", "manufacturer", "manufacturer-reference", "machine-manufacturer-reference"};
 
     for(QString key : keys)
     {
 
Modified: trunk/sources/nomenclature.cpp
===================================================================
--- trunk/sources/nomenclature.cpp    2017-10-02 14:46:26 UTC (rev 5058)
+++ trunk/sources/nomenclature.cpp    2017-10-02 16:59:53 UTC (rev 5059)
@@ -91,6 +91,7 @@
     ""+ QObject::tr("Position") +";"
     ""+ QObject::tr("Label") +";"
     ""+ QObject::tr("Désignation") +";"
+    ""+ QObject::tr("Description") +";"
     ""+ QObject::tr("Commentaire") +";"
     ""+ QObject::tr("Fabricant") +";"
     ""+ QObject::tr("Reference") +";"
@@ -147,6 +148,7 @@
     info += elmt-> diagram()-> convertPosition(elmt -> scenePos()).toString() + ";";
     info += autonum::AssignVariables::formulaToLabel(elmt_info["label"].toString(), elmt->rSequenceStruct(), elmt->diagram(), elmt) + ";";
     info += autonum::AssignVariables::formulaToLabel(elmt_info["designation"].toString(), elmt->rSequenceStruct(), elmt->diagram(), elmt) + ";";
+    info += autonum::AssignVariables::formulaToLabel(elmt_info["description"].toString(), elmt->rSequenceStruct(), elmt->diagram(), elmt) + ";";
     info += autonum::AssignVariables::formulaToLabel(elmt_info["comment"].toString(), elmt->rSequenceStruct(), elmt->diagram(), elmt) + ";";
     info += autonum::AssignVariables::formulaToLabel(elmt_info["manufacturer"].toString(), elmt->rSequenceStruct(), elmt->diagram(), elmt) + ";";
     info += autonum::AssignVariables::formulaToLabel(elmt_info["manufacturer-reference"].toString(), elmt->rSequenceStruct(), elmt->diagram(), elmt) + ";";
 
Modified: trunk/sources/qetapp.cpp
===================================================================
--- trunk/sources/qetapp.cpp    2017-10-02 14:46:26 UTC (rev 5058)
+++ trunk/sources/qetapp.cpp    2017-10-02 16:59:53 UTC (rev 5059)
@@ -284,6 +284,7 @@
     info_list << "formula"
               << "label"
               << "comment"
+              << "description"
               << "designation"
               << "manufacturer"
               << "manufacturer-reference"
@@ -307,6 +308,7 @@
     if (info == "formula") return tr("formule du label");
     else if (info == "label") return tr("Label");
     else if (info == "comment") return tr("Commentaire");
+    else if (info == "descrition") return tr("Descrition");
     else if (info == "designation") return tr("Désignation");
     else if (info == "manufacturer") return tr("Fabricant");
     else if (info == "manufacturer-reference") return tr("Référence fabricant");
@@ -330,6 +332,7 @@
     if (info == "formula")                             return QString("%{formula}");
     else if (info == "label")                          return QString("%{label}");
     else if (info == "comment")                        return QString("%{comment}");
+    else if (info == "description")                    return QString("%{description}");
     else if (info == "designation")                    return QString("%{designation}");
     else if (info == "manufacturer")                   return QString("%{manufacturer}");
     else if (info == "manufacturer-reference")         return QString("%{manufacturer-reference}");

Ce n'est pas très compliqué en soit mais ça peut devenir très chiant s' il faut en rajouter un certain nombre...
Pour moi, la difficulté se trouve du coté de la structure des attributs XML pour être compatible avec DEXPI et être interopérable avec d'autres logiciels, il y a quelques exemples mais pas de listes définies...

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: Utilisation de QET pour schémas PID

Ci-joint le schéma XML (XSD) fournissant la description syntaxique des fichiers XML à utiliser pour l'importation et l'exportation des P&ID, trouvé ici :
https://github.com/ProteusXML/proteusxml

Post's attachments

Attachment icon ProteusPIDSchema.xsd 87.21 kb, 360 downloads since 2018-07-18