Car j'ai crée le dialogue ainsi sans trop y réfléchir :p
Mais pourquoi pas.
Par contre pour les listes déroulante, les laisser en bas proche du bouton OK n'est il pas mieux, d'un point vue mouvement de souris ?

Pour l'histoire de liste de matériel vs bon de commande, je vais peut être dire une bêtise mais pour moi il est bien question d'une liste de matériel.
Un bon de commande s'adresse à un fournisseur (Il y a de forte chance qu'avec la liste/bon crée depuis QET tout ne soit pas commandé au même endroit ) de plus sur un bon de commande il n'y a pas qu'une liste, il y a le nom de ton entreprise avec des info comme adresse, fax, tel..... un numéro de commande et sûrement beaucoup d'autres choses.

Nuri wrote:

Non, non... Je ne voulais pas remettre les choses en question à ce point là.
Comme je disais, le dialogue est bien construit et très pratique, car on peut configurer à peu près ce que l'on veut.
Donc... Super ! Pas la peine de jeter le bébé avec l'eau du bain !

Ok je n'avais pas bien compris, donc tu verrais deux entrées "nomenclature" et "bon de commande" qui ouvre le dialogue, mais le dialogue ne proposera que les informations utile (nomenclature ou bon de commande).
A voir ce qu'en pense les autres (à coder c'est vraiment rien) personnellement je vote pour un seul dialogue, il suffit juste de créer ta requete la sauvegarder puis rappeler en fonction de ce que tu veut faire ensuite.
Par contre comme disais galexis, on peut renommer l'ensemble en "export csv" ce qui effectivement correspond plus à ce que fait le dialogue.

Nuri wrote:

1.
Un bouton d'aide pour faire apparaître une fenêtre qui explique la différence entre une nomenclature et un bon de commande, et comment le traitement des données diffère.

Il suffit de laisser la souris sur les lignes "Formater en..." pour faire apparaitre le tooltip. Bon j'avoue que ce n'est pas génial.

Nuri wrote:

2.
Un bouton d'aide dans la ligne de la requête SQL pour expliquer rapidement comment créer ses propres requêtes. Par exemple si je veux faire un bon de commande ne contenant que les composants de l'armoire 1 (alors que mon projet contient 3 armoires électriques, par exemple).

Expliquer comment est composé la bdd oui, après expliqué comment composer une requête c'est plus difficile, SQL est un langage. Après on peut mettre 4/5 exemples qui peuvent être utile dans notre cas.

galexis wrote:

e nom des champs "numéro d'article" et "numéro de commande" n'ont jamais été clairs pour moi, et cela était confirmé par le fait qu'à l'export "numéro d'article" apparaissait comme "désignation" ....


Ça a été un gros fouilli ce truc quand ça a été mis en place, et ça se ressent dans la code : numéro d'article -> désignation.
Quand j'ai codé la bdd pour l'export, j'ai cru à un bug au début car je ne me rappelais plus de tout ça.
Après numéro d'article et numéro de commande il y festo qui fonctionne comme ça, exemple avec un vérin depuis leur site web :
vérin compact
ADN-12-10-A-P-A                ->doit être la designation
N° de pièce: 536205           ->doit être le numéro de commande (ou l'inverse nomicons/tongue)

@Nuri,
je trouve ça un peu contre productif de créer des entrées 'nomenclature' et 'liste de matériel', si par la suite on affiche un dialogue avec uniquement les information utile qu'il faudra choisir, ou rappeler une configuration, à ce compte la autant rester comme c'est actuellement car on perd la rapidité visé initialement.
En revanche si on fait les entrées 'nomenclature' et 'liste de matériel', qui exporte directement en csv les informations concerné (mais non configurable par l'utilisateur) alors la oui, ça à du sens et c'est rapide.
On peut garder une troisième entrée "export csv personnalisé" où la on utilisera le dialogue.

Je me rend compte que les radio buttons, tous | borne | bouton/commutateur est trop restrictif.
Toi et Laurent avez raison il vaut mieux avoir des check box pour chaque type | sous type afin d'avoir un choix inclusif et non pas exclusif.

Après réflexion c'est vrai qu'une grande partie du temps, l'utilisation de l'export sera pour la nomenclature (quoique minime une fois integré dans le projet), liste de matériel, impression (label de bornier, label d'élément simple + maître 'tous type', commentaire de bouton), donc un sous menu export dans le menu projet serait légitime.

galexis wrote:

ce qui me dérange plus c'est les labels basés sur formule manquant dans l'export qui me gène ...  ;-)

T'inquiète pas, ce sera fait nomicons/wink

galexis wrote:

J'ai une question: A priori c'est une base SQLITE. Où est-elle stockée ? Dans le projet ou dans QET ? Momentanée ou permanente ?
Je me disais qu'on pourrait peut-être cs servir de cette base de donnée pour faciliter le remplissage des références/constructeurs/description textuelle ? Lors de la saisie dans un de ces 3 champs, on va taper dans la base de donnée et on propose des saisie précédentes ....

Elle est momentanée dans le code, en revanche il est possible de la sauvegarder.
Oui et non, la bdd est crée à la volé lors de l'export donc pas utilisable en l'état pour saisir les informations d'élément.
La vraie solution (et j'ai déjà cogiter sur le truc par le passé) c'est une bdd article constructeur avec les 3 infos que tu cite (avec description textuelle traduis) et un dialogue permettant d'ajouter, modifier cette bdd, puis lors de la saisi des infos d'élément puiser dans cette bdd.
Et le must si tu connais la ref, tu rentre uniquement la ref et tout le reste se remplira tout seul.
Mais bon la on s'écarte du sujet....

scorpio810 wrote:

C'est plus facile à lire pour un humain que le XML..

Et aussi à coder, moins verbeux que le xml, et c'est très adapté pour ce genre de choses à stocker.

Double clic -> OK nomicons/wink

Galexis wrote:

- la sauvegarde de configuration est un peu déroutante mais très pratique. Quand on choisit une configuration enregistrée, c'est la requête SQL qui s'affiche et non l'affichage graphique qui indique le contenu de la configuration. Du coup la modification d'un configuration ou même juste la lecture de celle-ci n'est pas évidente au commun des mortel.

Oui j'y avais pensé mais avais laisser tel qu'elle car demandais plus de boulot, et je me suis dit que si le besoins s'en faisais ressentir on ne manquerais pas de me le dire nomicons/wink
Je vais donc corriger ça pour les requêtes crée depuis le dialogue, pour les requêtes perso le comportement sera le même.

Pour les autres demande, c'est du détails ce sera corrigé.

galexis wrote:

La question que personne n'a encore posée : est-ce que la création d'un élément nomenclature va en découler ? Je suis en ce moment sur un projet où j'ai beaucoup de plans à créer et cela m'éviterait de les générer à la maison avec mon script bash....

Non !!
Plus sérieusement, la nomenclature ne sera pas crée depuis ce dialogue car dédié à l'export.
En revanche du code sera probablement partagé (la bdd), et j'ai des nouvelles idées sur les fonctionnalitées à ajouter. D'ailleurs il faudrait que je mette à jours mes idée ici https://qelectrotech.org/forum/viewtopic.php?id=1489

Merci Nuri nomicons/smile

Il y a des choses sur lesquelle je suis d'accord, et d'autre moins.
Sur le fait de mieux séparer le menu "projet" par la suite, c'est sur que ce serais mieux surtout par rapport à ce qui AJOUTE DANS LE PROJET et ce qui EXPORTE DEPUIS LE PROJET, en revanche créer une entrée "nomenclature" et une "seconde bon de commande" je suis pas vraiment pour.

Dans le principe je comprend, mais en pratique on passera par le même dialogue avec 2 configurations différente, donc pourquoi faire deux entrées dans le menu, d'ailleurs c'est dans ce but que j'ai crée la sauvegarde/rapelle de configuration, afin que chacun puisse créer l'export qu'il souhaite.

Toujours dans l'idée d'être souple et paramétrable, j'ai mis une option pour filtrer les éléments par bornier afin d'exporter un csv des labels de bornier pour impression, et par bouton/commutateur pour exporter en csv les commentaires pour impression des portes étiquettes.
Si on suit ton idée, il faudrait créer 4 entrées juste pour ce qui est faisable par défaut dans qet.
Peut être faut-il nommer le menu différemment ?

Pour finir je dirais :
Bon, j'arrête là pour pas encore faire un pavé indigeste et attends vos commentaires pour de plus amples développements...

Ba pour le coup, on peut oublier tout ça, car obsolète depuis mon dernier commit.
En revanche si il existe toujours des incohérences avec le nouveau générateur, il faudra remonté ça dans le topic https://qelectrotech.org/forum/viewtopic.php?id=1521 (galexis à déjà commencé).

Bonjour Eric,
merci pour les compliments.

À l'heure actuel il n'est pas possible d'inclure directement une nomenclature dans QET.
Pour cela il faut passé par l'export en csv.
En revanche la création de nomenclature directement dans QET est prévue pour la future version :  https://qelectrotech.org/forum/viewtopic.php?id=1484

La version 0.61 est une vieille version, utilise la 0.7 qui est la dernière version.

L'export de la nomenclature à été totalement réécrit.

-Il est maintenant possible de choisir quelle informations exporté ainsi que l'ordre dans lequelle celles ci doivent être affiché.
-Une option permet de filtrer par type d'élément : tous, bornier, bouton/commutateur.
-Une autre option permet d'afficher ou non les en-têtes de colonne dans le fichier csv.
Avec ces option, il est possible de crée une nomenclature, une liste de commande, mais aussi pour l'impression des labels : liste des borniers et liste des boutons  / commutateurs.
-Il est possible d'enregistrer/charger une configuration facilement.
Enfin le travail étant effectué par une base de donné SQLite, un champ de texte permet à l'utilisateur de crée sa propre requête SQL.

Ho le boulet nomicons/angel, la mémoire me reviens après avoir relu le code.
Lorsque j'ai refais le panel d'élément avec le multi-threading, le cache sqlite était un goulot d'étranglement lorsque l'on cherchais les noms (plusieurs thread accèdent à la même bdd) du coup j'avais viré ça.
En revanche les pixmaps sont toujours mis en caches, mais ils ne sont pas créent lors de la créations de la bdd, mais la première fois que l'on en a besoins (c'est à dire qu'un dossier d'élément que vous n'avez jamais ouvert n'existe pas dans la bdd), ce qui explique que lorsqu'on efface la bdd puis relance qet, celle ci pèse très peu.

Il serais peut être bien de mettre une option pour utiliser ou nom la bdd pour les noms d'éléments, car sur un pc mono-coeur avec un vieux hdd, la bdd est très utile, en revanche un pc avec 8 coeurs et un sdd c'est autre chose.

Il serais aussi intéressant que je me documente sur les accès parallèle sqlite.

Effectivement même chose sur un pc Windows, je sais ce qu'il me reste à faire nomicons/wink

J'ai crée une fonction pour exporter en csv les numéros de fils dans le dernier commit. C'est très minimaliste, vous choisissez uniquement où sauvegarder le csv. J'ai pris en compte tes remarque Christophe.
À tester.

Hum j'ai vraiment du mal avec ce bug nomicons/sad 
Par contre le truc qui est vraiment étrange c'est que ton fichier soit vide, mais aussi le fichier de backup qui lui aussi fait 0 Ko car dans le code ceux sont deux fonctions différente (la sauvegarde et le backup) mais qui visiblement donne le même résultat.
Ça pourrais donc laisser croire que le problème vient d'avant l'écriture dans le fichier, mais d'un autre coté ça semble toucher que windows et qui du coup la seul différence avec les autres OS c'est l'écriture dans le fichier (dont je n'ai pas la main dessus).
Je pensais avoir réglé le problème en utilisant QSaveFile mais non.....
Bref tant de mots pour dire qu'au final je n'ai pas de solution mais je planche dessus.

Idem aux deux autres topic, nous parlerons ici de la fonctionnalité de liste de fileries.

-Pouvoir exporter au format csv, pour par exemple pouvoir imprimer les numéros de fil. D'ailleurs si des personnes ont des informations à ceux sujet, ils sont les bienvenues.
-Si il existe d'autre format de fichier pouvant être utilisé avec les imprimantes de numéro de filerie, nous pouvons essayer de créer ces fichiers en question.
-Pouvoir générer un/des tableaux sur les folios avec :
*numéro de fil
*Dans le cas d'un potentiel comportant qu'un seul fil, afficher dans le tableau les deux élément auquel ce fil est raccordé (idéalement le nom de la borne de l'élément, mais cela n’existe pas encore dans qet)
*Pour les autres cas, le nombre de fils du potentiel + le nom des éléments raccordé.
*Affiché les infos du conducteur.

Fixed in the last commit.
Thanks for report.

Dans ce post seront établie toutes les fonctionnalités de la nomenclature intégré, bien entendue celui-ci n'est pas figé et sera mis à jour au fur et à mesure des discussions.

Tout d’abord je pense continuer à garder (et faire évoluer en parallèle de la nouvelle nomenclature) l'export car peut toujours servir pour par exemple une commande de matériel.

-Choisir de qu'elle colonne affiché ainsi que leurs position.
-Choix de la police (pour les entêtes et le tableau)
-Ajustement auto (taille de la police, position) sur le folio ou manuel
-Afficher la quantité quand une même référence est utilisé plusieurs fois.

pour en revenir à ce sujet : https://qelectrotech.org/forum/viewtopi … 584#p10584
Je pensais faire quelque chose dans le genre (je penche pour le cas N°2), en revanche ce qu'il me pose plus de problème, c'est comment on définie cela sur le schéma ??
Car au final ce sera (pour le cas d'un 3 étages) trois bornes différente sur le schéma mais qui représente un seul élément physiquement.

scorpio810 wrote:

+ champs informations sur la borne, infos qu'il est difficile de mettre en place sur le schéma mais qui doit être présent dans le dessin du bornier à moins que t'ais prévu qu'on puisse y ajouter des textes dynamiques comme avec les anciens borniers?

Non je n'ai pas prévue de mettre en place des textes dynamique (après on peut toujours étudier la question), en revanche c'est tout à fait possible d'écrire l'information comme sur ton folio.

galexis wrote:

Il serait peut-être bien que lors de la définition  du bornier, qu'on renseigne à ce niveau là, la référence et le fabricant des bornes utilisées pour avoir une fois généré la quantité totale de la référence de borne à commander (nomenclature).

Bonne idée.

galexis wrote:

Un truc que ne fait pas le générateur de bornier aujourd'hui, générer les bornier en fonction de l'installation et de la localisation. Si on a -Xc dans +BJ1 et -XC dans +BJ2, le générateur ne fait pas le distingo.

C'est noté.

444

(29 replies, posted in Code)

Because the Xref is update When you move the master.
What you need to do is when you change the alignment properties, you need to force the update of the displayed Xref

Lien de la discussion autour du générateur de borniers.
https://qelectrotech.org/forum/viewtopic.php?id=1486

J'ai relu à plusieurs reprise, mais je t'avoue que je n'ai pas compris nomicons/angel .
Peut-tu ré-expliquer, peut être avec un bout de dessin?

Grosse mise à jour de ce topic :
Dans ce premier post je mettrais régulièrement à jours l’avancement du générateur de bornier, ce qui est fait, ce qui reste à faire, les idées etc.… Vous pouvez continuer à alimenter ce sujet avec vos questions idée et autre.


==FAIT==
-Fenêtre de gestion des borniers
-Création/Modification/Modification de groupe de borne avec les informations suivantes : =Installation, +Localisation, Nom, Commentaire, Description.
-Ajouter des bornes présente sur les folios dans un groupe de borne depuis la fenêtre de gestion des borniers.
-Borne multi étage (4 max).
-Pont de borne
-Édition basique des propriétés de borne depuis la fenêtre de gestion des borniers (label, type, fonction, led)
-Positionnement automatique des bornes (ATTENTION par le passé une borne avait comme label par exemple X1:10, avec le gestionnaire de bornier la borne devra avoir comme label uniquement 10 et être dans le groupe de borne X1, sont identifiants intégral sera donc X1:10)
-Ajouter / supprimer un plan de borne sur un folio.
-Sauvegarde / restauration de la définition / structure d’un groupe de borne depuis le fichier .qet.
-Sauvegarde / restauration des plans de borne présent sur un folio depuis un fichier .qet
-Double cliquer sur un plan de borne ouvre la fenêtre de gestion des borniers

==BRICOLAGE==
-Une icône dans la barre d’outils permet d’ajouter un bornier sur le schéma.

EN COURS (branche de développement)
-Paramétrage de la représentation d’un plan de borne.
-Plusieurs jeux de paramètres disponible

==A FAIRE==
-Fenêtre d’édition en masse des propriétés de bornes (ref, constructeur etc.)
-Ajouter une nouvelle variable de formule de label qui indique le numéro de fil (ainsi la borne pourra avoir comme label le numéro de fil raccordé)
-Ajouter une nouvelle variable de formule de texte dynamique afin d’afficher le nom du groupe de borne parent (par ex X1).
-Créer un système qui permet d’assigner automatiquement une borne à un groupe de borne lorsque l’utilisateur pose une nouvelle borne sur le schéma.
-Quand on double clic sur la cellule des Xref du gestionnaire de bornier, le schéma bascule bien sur la borne mais il n'y a pas de halo bleu sur la borne, voir pour ajouter ça.
-Filtrer les bornes libre (Je pense que des filtres par folio/ label serait intéressant d’être ajoutés dans le tableau des "bornes libres", afin de faciliter la recherche et le tri dans le futur. Exemple comme dans ta vidéo classer les bornes par leur position dans les folios, ou par nom, ou par nom des conducteurs liés, etc.)
-Pouvoir partager le potentiel électrique au travers de borne n'ayant que une borne de connection mais étant ponté sur d'autre borne.
-Réactiver l'édition des propriétés des éléments de type bornes dans l'éditeur d'élément.

==IDÉE A ANALYSER==
-Comment gérer au niveau de la nomenclature une borne multi étage ? Sur le folio ce sera 3 éléments borne, ces 3 borne seront groupées ensemble dans le gestionnaire de bornier, pour de vrai c’est une seule pièce.        Probablement mettre en place la notion de référence de composant non affiché sur le folio (par exemple l’armoire électrique elle-même) et avec cette notion pouvoir y rattacher 1 à N élément présent sur le schéma.
-Représenter le plan de borne sous forme de tableau.
-Il semblerait que dans d’autre logiciel les connecteurs (prise harting, connecteur normalisé etc... ) sont gérés de la même manière que des bornes. Votre avis.
-Pour l'entête, il serait peut-être bien de pouvoir afficher ou non la localisation et installation.

==NE SERA PAS FAIT==
-Les câbles brancher sur le bornier, car les câbles dans qet n’existe pas à l’heur actuel.

448

(0 replies, posted in News)

Bonjour,
voici les résultats du sondage crée pour la version 0.8.
Vous avez été 46 personnes à effectuer ce sondage.
La fonctionnalité principal retenue est donc le générateur de bornier.
Les deux fonctionnalités secondaire sont la liste des fileries ainsi que la nomenclature intégré.

Toutes l'équipe remercie les participants.

hello,
here is the result of the survey of the new features to be added for 0.8 version.
You was been 46 persons to conduct the survey.
The main functionality will be the terminal block generator.
The two secondary functionnality will be liste of wire and integrated nomenclature.
All the team thanks the participants


Commentaire laissé lors des votes.
*============================================*
I think a cabe list would be great! But I read the comment when selecting it in the "main functionality" drop down, and I agree it makes sense to concentrate on the terminal block generator first.
*============================================*
A big thank for your amazing work!! Keep on going.
*============================================*
st es nicht einfacher und auch übersichtlicher eine Tabelle als Klemmenplan (ähnlich dem Inhaltsverzeichnis) zu entwerfen, bei der dann auch Klemmen mit mehreren Anschlüssen =X3:55a, =X3:55b, =X3:55c, =X3:55d dargestellt werden können? Für einen Klemmenplan ist die Benennung der Anschlüsse, Element Terminals unerlässlich.
Leider ist mein englisch nicht besonders gut. Grüße aus Oberschwaben Alexander Hopp
*============================================*
For the wire numbering please include an underline under the 6. It is very easy to confuse the 6 and the 9 and has caused issues with our technicians. cheers!! John
*============================================*
My opinion is that QElectroTech has a level of development with enough features for the actual status of the project.
The development has to be focused on the workflow before continue adding features.
Focussing the efforts on QElectrotech project should be the actual priority.
This decision can make that the version 0.7 will be during long time the stable version but continue developing features without a clear definition of the QElectroTech workflow to manage big projects will put the developers on the risk of rewriting many of the new possible features once QElectroTech project development continue.
The project structure according IEC 81346 can force some code modifications at the cross reference between elements, element properties, folio ordering system, folio properties, etc.
*============================================*
a standarzied and smaller version of the en 60617 symbols. (for example the thermal fuse has no standart size) a better editor with svg import option and scale with locked ratio by pressing ctrl or buttun ...) the wiring tools have to be in the toolbar (mean the T conection to left, right, buttom, up, as well as the corners)
*============================================*
I am so glad you are continuing developing QET. Best Regards /Morgan Leijström
*============================================*
1) add additional text boxes for wires like for elements.
2) copies of the conductors tag. Then you can in the beginning of the wire to specify its label and at the end of the wire.
3) if it were possible to get a table with connections - a wire label, its type, other parameters (for example, length, entered by the user), the element is the beginning, the element is the end, the color. But now everything is fine, thanks!) Goog luck!
*============================================*
Super logiciel que j'utilise tous les jours dans le cadre de mes études. La correction du crash systématique est une très bonne nouvelle, merci !!
*============================================*
Bonjour vous faites un super boulot.
*============================================*
La génération des borniers automatique serait un véritable gain de temps sur les projet. Il faudrait également repenser le système d'auto-numérotation, très trivial et pas souple. Bon courage pour le développement de ce merveilleux logiciel !
*============================================*
Pour que le programme puisse toucher un maximum de personne surtout chez les professionnels, il est important qu'il suive la norme. La ou je travaille (usine Coca-Cola de Marseille) tous nos plans suivent cette norme. Elle est d'ailleurs imposer à nos sous-traitant.
*============================================*
Merci beaucoup pour ce logiciel et bon courage pour la version 0.8 nomicons/wink




https://download.qelectrotech.org/qet/forum_img/resultat_sondage_fr.pnghttps://download.qelectrotech.org/qet/forum_img/resultat_sondage_en.png

449

(29 replies, posted in Code)

Thanks to your contribution nomicons/smile

Oui c'est tout à fait possible de supprimer les divers fichier de conf, avec un petit avertissement avant l’opération afin de prévenir l'utilisateur que l'action est irréversible.

scoprio810 wrote:

Bah il suffit de supprimer des morceaux du fichier config de QET, alors c'est vrai sous Linux et macOS

Sans vouloir prendre les utilisateurs pour des idiots, c'est déjà trop avancé comme méthode amha (et on parle que de mac et linux).

Et puis bon si je met des boutons pour se rendre dans les dossiers concerné plus la possibilité de faire une raz depuis qet, je pense que ça couvre tous les besoins cité ici.