226

(8 replies, posted in Chez nous les Pros)

Salut thierryR,

A l'exemple de Legrand, on voudrait un assistant à l'élaboration des tableaux de protections.

J'ai déjà fait plusieurs mises en armoire avec QET, dont celle-ci :
https://qelectrotech.org/gallery/photos … nsicht.png
Bon, faut être honnête, pour faire ca rapidement, il faut que tout soit bien préparé : dimensions folio, vignettes à l'échelle, etc. Mais quand tout est prêt, ca va vite, voire plus vite qu'avec les assistants des logiciels pros.

On aimerait mettre en fond de page un plan d'architecte et dessiner dessus.

Si le plan de l'architecte est dispo en image (jpg, png ou svg), il suffit de l'insérer sur un folio et de vérouiller sa position. Ensuite, placer les symboles de prises, interrupteurs, etc. Je vois pas ce qui empêche de faire cela actuellement.

Puis on voudra faire des métrés et ainsi sortir une liste de matériel à utiliser.

Pareil, c'est déjà faisable en l'état actuel du logiciel.

En connexion avec un fabriquant comme Legrand, on y retrouvera les références matériel et les prix indicatifs.

mmh... moi aussi j'aimerais bien que quelques entreprises mettent la main à la pâte mais bon, l'équipe QET n'a pas de réel statut juridique avec lequel une entreprise a l'habitude de collaborer.
Après, QET est un projet totalement libre, tout le monde peut y contribuer, même les entreprises !

scorpio810 wrote:

Je pensai au fait que ça pourrait être parfois utile d'avoir pour le QtreeWidget un QlineEdit avec un petit  QCompleter basé sur la liste des items champ texte de l’élément : rechercher directement un item, filtrer, trier les items textes "champ texte" par ordre alphanumérique dans le même style que la recherche de liaison report folio/maître/esclave, mais c'est probablement inutile pour 90% des utilisateurs.

Bref ! du moment qu'on pointe un champ texte avec la souris dans l’élément  le focus est mis sur l'entrée correspondante dans le widget comme on peu le voir dans la vidéo ci-dessus, ce n'est pas très utile de compliquer le code pour si peu.

Normalement, les textes des bornes d'un élément devraient être réalisés avec des textes fixes non éditables. Pour ma part, j'utilise seulement les champs de textes quand il faut pouvoir les traduire (et donc les modifier) directement depuis l'éditeur de schémas. Par ex. "alim 24V" --> "power supply 24V".
Mais c'est vrai que si tu as un variateur de fréquence avec 60 bornes dont les textes sont des champs de texte et non des textes fixes, ca te fait une sacrée panoplie de textes dynamiques dans le widget "Propiétés de l'élément"...

Hallo Walter,

danke für den Tipp mit FAR!
Das Programm werde ich bestimmt demnächst brauchen.

Grüße

Joshua wrote:

il faut que tu ais déjà fais mumuse avec les "nouveaux textes dynamiques"

Fait.
Je tiens à signaler un comportement qui me plaît bien :
depuis l'éditeur de schémas, quand on clique sur l'élément, c'est l'onglet "informations" qui s'affiche et quand on clique sur un texte dynamique, c'est l'onglet "Textes" qui s'affiche.
C'est pratique et rapide !

Quelques petits souhaits de ma part :
1.
Quand on veut ajouter un texte dynamique depuis le widget "Propriétés de l'élément" en cliquant sur le bouton [+], ce serait bien que le QTreeMachin soit totalement ouvert (déroulé) par défaut, ca éviterait 3 clics de souris inutiles.
2.
Est-ce possible de faire bouger les textes "en temps réel" avec les nouveaux champs X et Y ?
Pour l'instant, les textes changent de position seulement quand on valide la nouvelle valeur de X ou Y.

Joshua wrote:

Je trouve que ce comportement fait doublon avec les nouvelles possibiltés offertes par les "nouveaus textes dynamiques", car il est possible de créer un texte avec comme source de texte "commentaire".

Je voie les choses comme toi : ca fait doublon.
Dans le widget "Propriétés de l'élément", l'onglet "Informations" devrait à l'avenir simplement être destiné à entrer des infos, comme son nom l'indique.
Les check boxes pour "label", "commentaire" et "localisation" devraient disparaître.

D'où la réflexion suivante :
Est-ce qu'il faut mettre une check box (qui détermine, selon son état, si le texte est affiché ou non) pour chaque texte dynamique ?

Joshua wrote:

Une autre chose, trouvez-vous utile d'ajouter la fonctionnalité suivante :
Grouper ensemble les (nouveaux) champs textes d'un même élément.
Par exemple, vous avez 3 textes => grouper = agit comme un seul et même texte.

oui, ca peut être utile, surtout si tu arrive à faire :

Joshua wrote:

Alignement gauche/centré/droite des textes d'un groupe

Ca m'enlèverait une grosse épine du pied si je pouvais enfin aligner les textes à droite.

Joshua wrote:

je ne vous fais aucune promesse.

J'en ai bien conscience :-)


Petite correction au passage :
"Tag" s'écrit avec un seul "g" en anglais. On retrouve "Tagg" dans tout le code de QET. Un petit "chercher et remplacer" s'impose dans QtCreator !

Hallo Walter,

Wovon ist die Reihenfolge der Teile im Bibliotheksfenster abhängig ?

die Reihenfolge ist von den Dateinamen abhängig (alphabetisch).
Achtung: von den DATEInamen (*.elmt), nicht von den BAUTEILnamen (die man in verschiedenen Sprachen übersetzen kann).

Wie läßt sich die Farbe der einzufügenden Bauteile ändern?

Im Bauteileditor. Im Panel "Sammlungen", einfach auf ein Bauteil doppelklicken und es lässt sich dann im Editor komplett bearbeiten. Die Farben müssen dann für jedes grafische Element (Linie, Rechteck, Polygon, usw.) vom Bauteil einzeln bearbeitet werden.

Diagram editor : add in the tree widget use to edit the property of dynamic text item, two news items for edit the X and Y pos of the text.

Nickel!
Fini le placement des textes à la louche avec souris + Ctrl nomicons/smile

Joshua wrote:

Une fois qu'ils seront tous convertis, le bouton  "ajouter un champ texte" disparaîtra pour ne laisser que le bouton "ajouter un champ texte dynamique"

C'est vrai que pour le développeur, la nuance entre "champ de texte" et "champ de texte dynamique" est très importante.
Mais d'un point de vue utilisateur, les "champs de texte dynamiques", c'est comme avant mais avec des fonctionalités avancées.
Pour cette raison, je propose qu'on laisse la dénomination "champ de texte" et qu'on laisse le "dynamique" de côté quand les travaux seront achevés et qu'il n'y aura plus qu'un seul bouton dans l'éditeur d'élément.
Explication :
t'es nouveau sous QET, tu fais ton premier élément, et là, tu tombes sur "champ de texte dynamique" et tu te demandes :
"c'est quoi ce truc ? nomicons/blink "

Galexis wrote:

Le positionnement est relatif au label ?

nan nan, c'ets par rapport au hot spot de l'élément et c'est ca qu'est bien justement. Sinon, tu changes la position de ton label (par ex. parce que le texte est trop long et empiète sur le symbole) et la position de tous les textes changent ce qui serait assez pénible à l'usage...

Joshua wrote:

Pouvez vous me citer les cas ou vous avez besoins de rechercher du texte ?

- renommer un bornier -X1 en 28X2, par exemple (si le bornier a 150 bornes, t'imagines le boulot de faire ca à la main, borne après borne...)
- renommer une partie de machine (par exemple "Convoyeur pièces d'usinage" en "Chariot pièces") parce qu'elle a mal été nommée au tout début de la conception. Souvent, ce genre de texte apparaît sur plusieurs folios.
- renommer un gros câble multibrin (par ex. 24x2x0,34mm²) étalé sur 15 folios
- corriger une faute d'orthographe qu'on a copiée/collée 15 fois sur différents folios avant de se rendre compte de sa bourde

En fait, y'a pas que chercher et trouver du texte dans le .qet qui serait pratique mais surtout un chercher et remplacer avec un minimum d'intelligence :
chercher et remplacer
[ ] dans tous les textes du projet
[ ] uniquement dans tous les textes d'éléments
[ ] uniquement dans les labels des éléments
[ ] uniquement dans les cartouches
[ ] uniquement dans les champs de texte insérés sur les folios
[ ] uniquement dans les propriétés du projet
[ ] respecter la casse
La liste des options peut devenir assez longue si on veut vraiment cibler très précisément ce qu'on veut remplacer.

Quand je dois remplacer des textes, pour l'instant, je m'en sors avec un éditeur xml (XML copy editor), mais c'est un peu lourdingue (il faut fermer QET, ouvrir le gros xml avec l'éditeur, faire les modifs, redémarrer QET et réouvrir le projet .qet) et surtout dangeureux (on sait jamais trop si on va casser des attributs xml dans le .qet).

je ne suis pas certain de bien avoir compris ta question mais une chose est sûre, tu ne peux pas redimensionner les éléments une fois qu'ils sont placés dans la zône de dessin des schémas.

Pour modifier un élément (sa géométrie, sa taille ou un quelconque autre parmètre), il faut passer par l'éditeur d'élément. Comme ceci :
https://www.youtube.com/watch?v=EN4vstYDOlQ

Ensuite, avec les conducteurs, il suffit de les tirer avec la souris d'une borne du premier élément à une borne du second élément.

nomicons/pinch 
oui je voulais dire "pas un problème que la numérotation des colonnes commence par 1".

Tiens, pas mal tes icones de QET v0.7 sur ton screenshot nomicons/wink

scorpio810 wrote:

J'ai jamais vu de schémas électrique dont les repères de colonnes commence par zéro !

ben moi j'en vois beaucoup. Presque tous pour ainsi dire.
Je sais pas d'où ca vient cette habitube de commencer avec une colonne zéro.

Mais pour l'instant, pour mon boulot, personne ne m'a signalé que ce serait un problème que les colonnes commencent par 0.

Pour que Synaptic aille chercher la bonne version sur la ppa, il faut créer le fichier texte :
/etc/apt/preferences.d/40qelectrotech-devel

Et y taper le contenu :

Package: qelectrotech*
Pin: version 0.70.*
Pin-Priority: 1001

@ scorpio810 :

testé avec la svn5079 c'est mieux ! Merci !
Reste plus que le pointeur de la souris à modifier un de ces jours.

Already done :

https://qelectrotech.org/forum/viewtopi … 7141#p7141

scorpio810 wrote:

J'ai réduit la taille du "hoover" de moitié sur le commit svn 5075.
Normalement ça devrait aller mieux, par contre ce n'est pas encore ça pour les conducteurs courts.

J'ai compilé le svn5075 :

Je parlais de la taille du halo violet dans l'éditeur d'éléments (quand on sélectionne une shape), pas de la taille des poignées rondes.

Pour formuler autrement le problème :
dans l'éditeur d'éléments, quand on attrappe un truc avec la souris, c'est souvent difficile de savoir si on va redimensionner ou déplacer l'objet.
Et plus l'objet est petit, plus c'est difficile.

Pour reprendre l'exemple de mon cercle de 5px de diamètre (typiquement pour dessiner des bornes d'éléments de type black box), disons que j'arrive à le déplacer si j'accroche une zone bien précise autour du centre du cercle. Si je tape à côté, je redimensionne le cercle nomicons/getlost .

Le pointeur de la souris ne se modifie pas pour montrer à l'utilisateur s'il va redimensionner ou déplacer s'il clique sur la zône où le curseur se trouve.

super !
J'essaierai de développer mes idées dans un pdf.

Joshua wrote:

À noter que le temps de freeze est proportionnel à la taille du projet

Ca c'est clair, j'avais déjà remarqué. Ca peut durer parfois jusqu'à dans les 10 secondes. Mais bon, pas grave.

Et l'idée des X et Y pour les champs dynamiques ?

Captaindoc wrote:

Est ce moi ou le mode édition d'objet est devenue un calvaire ?

moi aussi j'ai bien lutté avec l'éditeur d'éléments ces derniers jours.
Essayez de dessiner un cercle de diamètre 5px et de le bouger sans le redimensionner systématiquement... nomicons/angry
Le "hoover" des entitées graphiques est trop gros ce qui fait qu'on attrappe pas toujours ce que l'on veut.
Plus les objets dessinés sont petits (quelques pixels) et plus c'est difficile.
Pour les objets plus gros (>20px), le problème se fait beaucoup moins sentir.

Sinon, dans l'éditeur de schéma, le plus simple pour faire un double-clic sur un conducteur, c'est encore de zoomer pour ne plus être dans la zone d'accroche des poignées bleues rondes. Sinon ton double-clic tombe à l'eau...

scorpio810 wrote:

Testé pour l'instant sur Win 7, Win 10, macOS pas de petite phase de freeze.
Essayes avec une VM Windows.

Je confirme : la petite phase de freeze est absente.
Testé sous Win10 virtuel.

@ scorpio810 :
j'avais compris que l'amélioratino de la vitesse de chargement était liée à l'upgrade de Qt. Visiblement ce sont 2 choses distinctes.

@Joshua :
j'ai fait quelques essais avec une v0.7 compilée (mieux qu'en Ubuntu virtuel) des champs de texte dynamiques. Miam, miam... ca donne faim, et plein d'idées surtout !
La première :
est-ce compliqué de rajouter la position X et Y du texte (relativement au hotspot de l'élément: X=0 et Y=0 signfie qu'on est sur le hotspot) en pouvant les régler avec ce widget incrémenteur/décrémenteur ?
L'idéal serait au pixel près.

https://download.qelectrotech.org/qet/forum_img/nuri_textes_dyn_position.png

@ scorpio810 :

je viens d'essayer avec mon plus gros projet (148 folios) sur une v0.7 compilée depuis le dernier trunk (svn5073) et, oui, j'ai l'impression que le chargement va un peu plus vite.
Mais j'ai toujours une petite phase de "freeze" (Ubuntu grise la fenêtre comme si elle ne donnait pas de réponse) de 3 ou 4 secondes juste après le chargement de tous les folios.
Mais si je me souviens bien, à l'époque où je bossais sur ce projet, la phase de "freeze" était assez longue. Peut-être 8 ou 10 secondes, ou peut-être plus, me rappelle plus trop.

scorpio810 wrote:

Pour Debian Unstable il faudra attendre un peu que les paquets soient disponibles sur les dépôts Debian officiels pour mettre à jour les chroots de compilation.

Est-ce que cela signifie que mon appréciation du temps de chargement plus rapide est bidon ?!?
Je suis toujours sur Ubuntu 16.04, donc à priori sur une base Debian Unstable, donc j'ai pas profité de ton upgrade de la version Qt ?
Ai-je bien compris nomicons/alien ?
nomicons/wassat

Bien !
En espérant que ce soit vraiment la cause du problème.

Merci Joshua pour ces précisions.
Je ne pense donc pas que ce soit une bonne idée de passer à la v0.7 pour faire du productif. Comme tu le sinales, il risque d'y avoir pas mal de chamboulements à l'avenir car le système des textes dynamiques n'en est qu'à ses débuts.
Je vais donc installer la v0.7 dans un Ubuntu virtuel. Ca me permettra de suivre le développement sans risquer de perturber tout ce que j'ai mis en place depuis plus de 2 ans pour satisfaire les demandes de mon client.

oui, je voulais dire bash nomicons/pinch

Dans le temps qu'il me faut pour écrire une macro fonctionnelle pour convertir toute ma collection, j'aurais largement tout retapé à la main. Malheureusement c'est comme ca quand on programme pas tous les jours, il faut beaucoup de temps...
(il m'avait fallu 3 semaines pour écrire la macro qui fait les éléments nomenclature).

Question à Joshua :
si je veux passer à la v0.7 maintenant, est-ce que j'ai des précautions particulières à prendre ? Est-ce que l'éditeur d'éléments va me convertir certaines propriétés automatiquement ?
J'aimerais bien passer sur la v0.7 pour commencer à commenter le travail sur les textes dynamiques... et aussi bien sûr pour chipoter un peu nomicons/tongue

scorpio810 wrote:

ajouter une nouvelle variable "Name provider"

pas besoin d'écrire "Name".
pour info, en anglais, fournisseur = supplier

Joshua wrote:

Bien le commit Laurent, du coup je me demande si le champ désignation est toujours utile?

Je fais un petit récapitulatif pour voir si on peut accorder nos violons :

D'après ce que j'ai vu dans mon expérience professionnelle chez divers clients et dans diverses branches industrielles, il y a toujours un socle commun de données d'article qu'on retrouve un peu partout. Ces données sont :
- le numéro d'article (donné par le fabricant du matériel)
- le numéro de commande (donné par le fabricant du matériel)
- le numéro interne (donné par l'acheteur du matériel. Souvent, ce numéro vient du service achats)
- la description textuelle (pour savoir de quoi on parle car les numéros ne sont pas d'une grande aide pour savoir en un coup d'oeil s'il s'agit d'une vanne, d'un transfo, d'un moteur, etc.)
- le nom du fabricant
Eventuellement aussi :
- le nom du fournisseur (car on achète pas toujours directement chez le fabricant)

Chez certains fabricant, il n'y a pas de différence entre le numéro d'article et le numéro de commande. Par exemple chez Siemens (6ES7...).
Chez d'autres fabricants, par exemple Phoenix Contact ou Eaton, le discernement est très clair.

Si j'essaie de mettre ces données dans les champs disponibles dans QET, cela donne :
- numéro d'article = désignation (QET)
- numéro de commande =référence fabricant (QET)
- numéro interne = référence fabricant machine (QET)
- description textuelle = description (QET), que Laurent vient d'implémenter
- nom du fabricant = fabricant (QET)
- nom du fournisseur = pas d'équivalent pour l'instant dans QET

Perso, je préfèrerai qu'on renomme :
"désignation" en "numéro d'article"
"référence fabricant" en "numéro de commande"
"référence fabricant machine" en "numéro interne"
pour la simple et bonne raison que ces dénominations sont plus parlantes. Et s'il faut renommer, alors maintenant, car joshua est en train de mettre un système en place sur lequel beaucoup d'utilisateurs vont investir beaucoup de travail. Just my 2 cents...