Éliminer certains éléments de la nomenclature (Page 1 of 3)

Bonjour Laurent.

Justement, parlant du tableur, ce n'est pas du tout pratique pour moi. Par convention dans ma société, la nomenclature doit figurer dans le document final, soit dans un encadré présent sur chaque feuille, soit à la fin du document PDF généré. Je ne vois aucune méthode pratique et rapide pour y arriver:

• soit générer la nomenclature en CSV, la modifier dans un tableur (éliminer lignes/colonnes inutiles), sauvegarder, imprimer dans un PDF, imprimer les schémas dans un autre PDF, ouvrir Gimp, ajouter un calque avec la nomenclature, ré-exporter en PDF.

• soit soit générer la nomenclature en CSV, la modifier dans un tableur (éliminer lignes/colonnes inutiles), copier, coller dans un champ texte de QE... et jusqu'à présent, je n'ai pas encore réussi à faire quelque chose de propre, qui me convienne et ne soit pas détruit par des éditions successives du champ texte riche (j'ai essayé de modifier la source [X|HT]ML directement mais c'est loin d'être pratique et idéal car, pour bien faire, il faut passer par un éditeur externe et, si j'ai le malheur d'y indenter le code pour plus de clarté, l'éditeur de QE bousille complètement le champ texte en ajoutant des lignes vides, une fois le texte collé en mode source.)

Quelle que soit l'option, ça m'a pris beaucoup plus de temps que ce que j'aurais souhaité et ce n'est qu'un schéma relativement simple. Donc, non, hélas, passer par un tableur n'est pas une option.

De plus comme je ne suis pas la seule personne à dessiner ce genre de schéma, je ne peux raisonnablement pas demander à tous les intervenants de passer par toutes ces étapes si jamais un composant est modifié, par exemple dans le cas d'une maintenance ou d'une référence devenue obsolète. S'il existait une case à cocher pour chaque composant, cochée par défaut, pour contrôler son apparition dans la nomenclature, ce serait déjà une bonne chose.

À la limite, je pourrais me charger du code pour récupérer cette liste. Je n'ai aucune expérience en programmation avec Qt mais, s'il le faut...

Merci. J'y jetterai un œil à l'occasion. Au fait, pourquoi CsvReader? Ne s'agit-il pas d'exporter? (Je ne vois en fait aucune fonction dans le code qui écrive un fichier.)

Prévois-tu une couche d'abstraction des sources de données? L'idée serait de fournir une interface, toujours la même à tous les consommateurs de données. De cette manière, on pourrait alimenter, par exemple, un tableau HTML avec une source statique comme un fichier CSV ou XML, un autre schéma QET, une base de données SQLite ou une source interne calculée comme la nomenclature ou le sommaire. Tu lies ainsi le code à l'interface plutôt que de le lier à la source. J'ai l'habitude de travailler avec les PHP Data Objects (PDO), c'est la raison de ma suggestion.

De même, la lecture et l'écriture de fichiers CSV a été traitée ad nauseam dans la plupart des langages et applications. Serait-il envisageable d'interfacer QET avec Python ou Perl par exemple? Le module csv de Python, par exemple, est déjà tout prêt et fonctionnel, ce serait dommage de réécrire le même code. D'un autre côté tu pourrais aussi accélérer le développement de manière considérable en permettant à d'autres développeurs (non spécialistes en C++ *et* QT) de fournir leurs propres modules.

Juste mes 2 eurocents ;-) .

On en avait déjà discuté avec Joshua sur le fait d'ajouter des plugins, librairies pour enrichir Qet avec par exemple des modules Python pouvant être développer par la communauté.

C'est toujours à l’étude pour intégrer le convertisseur DXF de Ronny dans l’éditeur d’élément.

Seulement on est pas des développeurs de métier, mais des techniciens de maintenance dans l'industrie.

A deux on ne peux pas exaucer toutes vos demandes, et même si le framework Qt facilite beaucoup de choses c'est loin d’être facile et à la portée du premier venu.

Notre seul avantage qui parfois est un inconvénient sur notre santé c'est de travailler en horaires d’équipe tous les deux ce qui nous laisse du temps libre en dehors de notre boulot pour s’occuper de Qet. Quand tu es du matin ou de nuit ça laisse plus de temps mais nos journées font parfois le tour de la pendule.. debout depuis 4h du mat faire sa journée de travail puis étudier réfléchir sur l’évolution de Qet ou débusquer un bug gênant jusqu’à  parfois 2, 3h du matin est fréquent.

Merci à ceux qui nous soutiennent par leurs dons, ça nous motivent et permet de renouveler notre hardware qui demande de plus en plus de puissance de calcul (machines de build de paquet, laptop de devel, nas en raid backup du projet etc). Ce hardware élitiste coûte souvent un bras..

@Nuri,
Certes, mais Paris comme dit le proverbe ne c'est pas construit en un jour..
Quand on vois l’évolution de Qet depuis 2006 il n'y a pas photo.
Et avec le départ de Xavier, on pensait pas pouvoir continuer, mais la 0.3 est quand même sortie, puis la 0.4, etc.
Pour l'instant la priorité est de finaliser le dock et éviter de faire 3 km de souris par jour, comme tu le dit si bien, et tu as bien raison.
Après la priorité numéro 1 sera d'étudier et surement revoir une grosse partie du code sur la comparaison des attributs XML dans l'arbre entre la lecture et l’écriture des définitions d’élément du projet.
Depuis peu, Qt n'en fait qu'a sa tête, et les attributs définition d'un élément ne sont jamais ré écrit dans le même ordre dans le XML root.
Ce qui fait que le même élément pose problème une fois le redémarrage de Qet et que le handler vous demande ce qu'il doit en faire :intégrer l’élément, écraser celui en cours, cohabiter les deux éléments...

@ tous
Ceci n'est pas une demande urgente de ma part, j'aimerais juste prolonger la réflexion sur l'histoire du csv, et donner mon point de vue sur le futur de la chose :

Je trouve très bien que QET exporte quasiment toutes les données des schémas en csv, cela permet de rester
flexible. Il ne faut pas oublier que QET est utilisé à quasiment toutes les sauces : électrique, hydraulique, pneumatique, schémas unifilaires d'installation, PID, mise en armoire, schémas logiques et programmation, électrotechnique pour automatisation... ca fait beaucoup ! Donc les besoins des utilisateurs sont très variés.

Une fois les données brutes exportées en csv, c'est à l'utilisateur de voir ce qu'il veut en faire. S'il est sous windows, il se fera des macros en Visual Basic avec Excel. S'il est sous Linux, il se fera des macros en Basic avec LibreOffice... Sachant qu'on peut aussi être sous windows et utiliser LibreOffice... bref, là aussi, les outils et systèmes sont assez variés.
Je pense qu'il faut laisser les tâches de tableur aux tableurs (Excel ou LibreOffice, ou autre chose) :
classer, trier, réordonner, effacer, chercher et remplacer...
D'une part, parce qu'ils font cela très bien et, d'autre part, parce que ce serait le bagne de coder toutes ces fonctions dans QET.

Ensuite, tous les tableurs peuvent enregistrer en csv et ainsi fournir un fichier qui sera réinjecter par QET dans le xml du projet *.qet.
Evidemment, cette interface manque encore. Et oui, il faudrait qu'elle soit paramétrable pour pouvoir définir :
- le nombre de lignes et de colonnes par folio
- les dimensions des lignes et colonnes
- la taille des polices (éventuellement)
- les titres des folios qui seront créés
- l'emplacement des folios dans la documentation...
Que faire des textes trop long ? Faudra-t-il les tronquer ? Les rapetisser ? Les mettre sur 2 lignes ?

@ Scorpio
en 2010, j'avais testé pour la première fois QET v0.22 sur les dépôts Ubuntu. Je me suis dit que jamais je pourrai bosser avec ce truc, à moins de mutltiplier mes prix par 3...
Donc oui, y'a pas photo, aujourd'hui je bosse avec QET v0.5dev, certes sur un petit projet et pour un seul client, mais quand même !
Beaucoup de choses ont évoluées dans le bon sens, sont devenues plus rapides et plus fiables. Et y'a aussi eu le passage à Qt5 qui n'était pas gagné d'avance... Continuez de finaliser le nouveau dock, avec le changement des données à la volée, c'est vraiment un plus.

@Nuri, avant avec Xavier c'etais un admin sys très doué en programmation, scripts divers mais pas électricien de formation, maintenant ce sont des électriciens qui codent pour des électriciens, et avec Joshua nous sommes les premiers à nous en servir autant dans notre travail ou en dehors.

Sinon pour Qt5, on n'avait plus le choix.

http://blog.qt.io/blog/2015/05/26/qt-4-8-7-released/

Bah si t'appelles un petit projet un truc de 150 folios certains ici vont tirer la langue... uhuhu

Laurent

@ Scorpio
ben je sais pas encore combien de folios j'aurais à la fin mais ce sera certainement moins de 150. La machine est petite : 7-8 moteurs, quelques capteurs, quelques vannes...
Fin de la semaine dernière, j'ai appris que c'est une machine pour les USA, donc il faut tout concevoir selon la norme américaine UL508A "industrial control panel"... Le cauchemar... Il faut tout repenser et je suis assez paumé.
Par chance, j'ai réussi à échapper aux symboles ANSI et je peux donc créer les nouveaux éléments selon IEC.

@ Galexis
si tu t'ennuies , y'a la documentation html d'Arun à traduire de l'anglais au francais. Ca commence à devenir un sacré pavé. Je comptais la faire mais là j'ai vraiment pas le temps. En plus, c'est pas toujours facile à traduire et il faut bien écrire pour que ce soit facilement compréhensible.

http://www.eaton.com/ecm/groups/public/ … 726860.pdf
C'est moi ou je trouve les symboles AINSi d'un autre temps...
Et du coup tu fais quoi, tu re bascules vers Eplan pour ce projet, ou Qet va mettre timidement un pied sur le sol américain/canadien du coup?
Pas sérieux ton client pour te dire ça une fois le projet lancé.

C'est surement une question d'habitude, mais j'aurai vraiment du mal à m'y faire ne serai ce que pour lire les schémas .

Le pire c'est les circuits commande chez eux, c'est dessiné en Ladder, tu te croirais dans ton automate avec ton pc.
Qet n'a pas été prévu dans ce sens (rung auto, numérotation des rungs)

http://qelectrotech.org/forum/viewtopic … 2029#p2029