26

Re: Nouveautés de la version de développement 0.7

À l'ouverture d'un élément dans l'éditeur d'élément, les champs texte non taggé (label, fonction, tension/protocole) sont automatiquement convertie en champ texte dynamique.

27

Re: Nouveautés de la version de développement 0.7

En pratique, si vous devez retoucher souvent un élément dans vos projets, il suffit de l'ouvrir avec l’éditeur et de l’enregistrer dans votre collection personnelle, l’éditeur effectuant la conversion automatiquement.
Apres il vous sera possible a partir du widget de changer la couleur, leur taille de police, et leurs textes à la volée.
Cela ne fonctionne que sur les champs texte et non sur les textes fixes.

28

Re: Nouveautés de la version de développement 0.7

Plop ! nomicons/smile

je suis pas très bavard en ce moment (chantier maison + boulot habituel) mais je suis le développement de QET.
Ca a l'air vraiment prometteur les champs de texte dynamiques.

Pour l'instant, je reste scotché sur la v0.6 car j'ai des plans à faire en urgence. Pas le temps d'apprendre des nouveaux trucs en ce moment.

Quand les textes dynamiques auront suffisamment été testés, je verrai si je passe toute ma collec perso sur ce système, histoire d'avoir les données d'article bien propres dans chaque élément.
A ce jour, j'ai 678 articles constructeurs dans ma collection perso. Faut voir comment je pourrai les convertir sans y passer 3 semaines à tout retaper à la main...
Ca sent le script batch à plein nez, mais je sais pas si je saurai faire nomicons/getlost

29

Re: Nouveautés de la version de développement 0.7

@Nuri : ça devrait te plaire. ;-)

Revision: 5057
Author:   blacksun
Date:     2017-10-01 17:25:34 +0200 (Sun, 01 Oct 2017)
Log Message:
-----------
Element editor : element informations (manufacturer, reference etc...) can be created directly from the element editor. For that go to the widget "Element Property"

https://download.tuxfamily.org/qet/forum_img/element_Property.png
https://download.tuxfamily.org/qet/forum_img/element_Property1.png

30

Re: Nouveautés de la version de développement 0.7

Joli ! Nuri va être comme un dingue !

31

Re: Nouveautés de la version de développement 0.7

Nuri wrote:

Plop ! nomicons/smile

je suis pas très bavard en ce moment (chantier maison + boulot habituel) mais je suis le développement de QET.
Ca a l'air vraiment prometteur les champs de texte dynamiques.

Pour l'instant, je reste scotché sur la v0.6 car j'ai des plans à faire en urgence. Pas le temps d'apprendre des nouveaux trucs en ce moment.

Quand les textes dynamiques auront suffisamment été testés, je verrai si je passe toute ma collec perso sur ce système, histoire d'avoir les données d'article bien propres dans chaque élément.
A ce jour, j'ai 678 articles constructeurs dans ma collection perso. Faut voir comment je pourrai les convertir sans y passer 3 semaines à tout retaper à la main...
Ca sent le script batch à plein nez, mais je sais pas si je saurai faire nomicons/getlost

Pour te donner une idée des nouvelles propriétés "information" sur les éléments : 

<definition height="70" link_type="simple" hotspot_x="39" orientation="dyyy" hotspot_y="36" type="element" version="0.70" width="80">
    <uuid uuid="{8569b90d-8b4f-4dd7-8b29-e779db64f0a7}"/>
    <names>
        <name lang="en">VUVG-L18-P53C-T-G14-1R8L (8031534)</name>
    </names>
    <elementInformations>
        <elementInformation show="1" name="machine-manufacturer-reference">xxxxxxxxx</elementInformation>
        <elementInformation show="1" name="comment">Solenoid valves VUVG</elementInformation>
        <elementInformation show="1" name="designation">8031534</elementInformation>
        <elementInformation show="1" name="manufacturer">FESTO</elementInformation>
        <elementInformation show="1" name="manufacturer-reference">VUVG-L18-P53C-T-G14-1R8L</elementInformation>
        <elementInformation show="1" name="label">V1</elementInformation>
    </elementInformations>
    <informations>Author: The QElectroTech team
License: see http://qelectrotech.org/wiki/doc/elements_license</informations>
    <description>
        <text text="+/-" size="4" y="8" x="17"/>
        <arc height="6" start="-180" angle="-84" sty............
 
couic...

32

Re: Nouveautés de la version de développement 0.7

Bonjour,

Énorme avancée.

Mais pour moi, il faudrait que la désignation soit multilingue, avoir un code article (fabriquant), une référence article (fabriquant) et un code interne à l'entreprise.
Code interne pour rédaction des devis, c'est le métreur qui parle.

Bonne journée

33

Re: Nouveautés de la version de développement 0.7

Salut baboune41.
Pour la partie multilingue, j'y ai fortement pensé durant le développement.... c'est faisable, mais implique des changements dont j'ai du mal à en mesurer l'importance.
J'imagine que c'est pour pouvoir imprimer les schémas sous différentes langues sans être obliger de se coltiner tout le projet. J'ai bien d'autre idées sur le sujet, mais il faudrait ouvrir un autre topic pour ça.
Pour le code interne, c'est déjà existant il s'agit de "référence fabricant machine".

34

Re: Nouveautés de la version de développement 0.7

@ Baboune41 : bonne remarque, mais es-ce vraiment utile en pratique ? 

Déjà qu'il est impossible d'avoir une collection entièrement traduite dans toutes les langues juste sur le nom de l’élément, j'imagine le reste.

le but est de se passer d'une base de donnée pour stocker les diverses références constructeur. ces informations étaient vraiment pénibles à rentrer manuellement à chaque fois jusqu’à présent ! Et sur chaque élément posé sur le schéma.

A part le champ "comment" et encore ... les autres n'ont pas besoin d’être traduisible en plusieurs langues, une fois l’élément posé sur le folio, toutes ces informations sont modifiables symbole par symbole par le widget information.

@ Joshua : en principe non, ces informations servent surtout pour extraire et produire une nomenclature, en passant par l'export vers un tableur en csv et la macro LO de Nuri pour générer ces folios nomenclature. 

Il est donc très facile de manipuler ces données une fois exportées dans un tableur, les traduire si besoin et les remplacer en lot pour les quelques informations qui en ont besoin, régénérer la nomenclature par les macro.

35

Re: Nouveautés de la version de développement 0.7

baboune41 wrote:

Bonjour,

Énorme avancée.

Mais pour moi, il faudrait que la désignation soit multilingue, avoir un code article (fabriquant), une référence article (fabriquant) et un code interne à l'entreprise.
Code interne pour rédaction des devis, c'est le métreur qui parle.

Bonne journée

Je me rappelle avoir vu que Nuri avait proposé une nouvelle liste, il serait utile de voir vos propositions et d'en débattre.
Il est très facile de rajouter de nouvelles informations mais c'est quand même un long travail ! ça touche beaucoup de code dans le programme.

Si vous avez des idées pour améliorer cette liste c'est le moment de les proposer. ;-)

36

Re: Nouveautés de la version de développement 0.7

nomicons/cool
classe, c'est une grosse avancée ! Depuis le temps que je vous tanne le cuir avec ces machins...
Je rejoins Baboune41 pour l'aspect traduction : il faut pouvoir traduire, c'est super important car les machines partent aux 4 coins du monde.
Cependant, le seul champ qui nécessite une traduction est le champ "description". Par exemple, avec la vanne ci-dessus :
[fr] électrovanne, distributeur 3/2, bobine 24VDC
[en] solenoid valve, 3/2 ways, 24VDC coil
[de] Magnetventil, 3/2-Wege, Spule 24 VDC
Les autres champs n'ont pas besoin d'être traduit car identiques dans toutes les langues.

D'ailleurs je pense qu'il faudrait séparer "commentaire" et "description".
"Description", c'est pour décrire textuellement l'article dont il est question alors que "commentaire", c'est plutôt pour afficher un détail important sur le folio (par ex. "arrêt d'urgence" ou autre).

Joshua wrote:

Pour la partie multilingue, j'y ai fortement pensé durant le développement.... c'est faisable, mais implique des changements dont j'ai du mal à en mesurer l'importance.

peut-être pas si compliqué que cela :
à l'heure actuelle, j'utilise le nom de l'élément (qu'on peut déjà traduire) pour rentrer les données d'article. Pour chaque article constructeur, je rentre toujours les données d'article en francais, allemand et anglais. Si je veux exporter ma nomenclature en anglais, je configure QET en anglais et QET me sort les noms des éléments en anglais dans le csv. Après, comme d'hab, la macro fait le reste et les éléments nomenclatures sont tous en anglais.
Donc... il faudrait s'appuyer sur la partie du code de la génération csv qui utilise le nom des éléments.

scorpio810 wrote:

Déjà qu'il est impossible d'avoir une collection entièrement traduite dans toutes les langues juste sur le nom de l’élément, j'imagine le reste.

C'est pas grave. Pour preuve : QET est quand même utilisé sur toute la planète.
L'essentiel pour l'instant c'est d'avoir au moins la possibilité de traduire. Les bibliothèques s'étofferont au fur et à mesure.

scorpio810 wrote:

Je me rappelle avoir vu que Nuri avait proposé une nouvelle liste, il serait utile de voir vos propositions et d'en débattre.

Moi je veux bien mais c'est ma liste à moi qui répond à mes besoins donc c'est peut-être pas la panacée de partir de là.
Le problème c'est que cette liste risque de devenir énorme et au bout du compte on aura une nomenclature csv avec une bonne centaine de colonnes... et là... ca devient lentement ingérable...

Je propose une autre idée :
pour l'instant on a 2 blocs auxiliaires pour rentrer des informations personnalisées et non identifiables à priori. Pourquoi ne pas étendre à 20 ou 30 blocs auxiliaires, ou même plus si nécessaire ?
Dans le widget de l'élément, j'imagine ca comme un tableau à 2 colonnes (nom de la propriété et sa valeur) qu'on peut ouvrir ou fermer (facon déroulage/enroulage) sinon il prendrait trop de place dans le widget.
Après, il faudrait pouvoir configurer l'export csv, par exemple en affichant avant l'export, un petit dialogue avec quelques check boxes, dans le genre :
Voulez-vous également exporter les informations suivantes :
[ ] donnés d'article
[ ] blocs auxiliaires 1 à 10
[ ] blocs auxiliaires 11 à 20
[ ] blocs auxiliaires 21 à 30

je vous laisse commenter avant d'aller plus loin...

37

Re: Nouveautés de la version de développement 0.7

D'ailleurs je pense qu'il faudrait séparer "commentaire" et "description".
"Description", c'est pour décrire textuellement l'article dont il est question alors que "commentaire", c'est plutôt pour afficher un détail important sur le folio (par ex. "arrêt d'urgence" ou autre).

Voila nouveau champ description ajouté.
Revision: 5059
Author:   scorpio810
Date:     2017-10-02 18:59:53 +0200 (Mon, 02 Oct 2017)
Log Message:
-----------
Add new description field

38

Re: Nouveautés de la version de développement 0.7

@ scorpio :
super le commit, ca évitera les confusions.

@ Jushua :
je pensais à un truc :
est-ce que le moteur de recherche des collections sera capable de trouver les infos contenues dans les nouveaux champs que tu viens d'implémenter ?
Par exemple, avec la vanne ci-dessus, si je tape "VUVG", ce serait bien que tous les éléments contenant ce texte soient affichés.
Pour l'instant (avec la v0.6) comme j'écris la référence "VUVG-L18-P53C-T-G14-1R8L" dans le nom de l'élément, le moteur me trouve l'électrovanne tout de suite et c'est vraiment super pratique (nettement plus rapide que dans Eplan où y'a plusieurs clics intermédiaires avant de trouver ce qu'on cherche dans une base de données énorme.)
Ce serait dommage de perdre la fonction du moteur de recherche en cours de route...

39

Re: Nouveautés de la version de développement 0.7

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

Nuri wrote:

je pensais à un truc :
est-ce que le moteur de recherche des collections sera capable de trouver les infos contenues dans les nouveaux champs que tu viens d'implémenter ?
Par exemple, avec la vanne ci-dessus, si je tape "VUVG", ce serait bien que tous les éléments contenant ce texte soient affichés.

Oui je pense que c'est faisable, il faut que je garde ça sous le coude.

Nuri wrote:

Ce serait dommage de perdre la fonction du moteur de recherche en cours de route..

Pourquoi cette fonction viendrais à disparaître?

40

Re: Nouveautés de la version de développement 0.7

@ Joshua :
tu m'as mal compris. Je voulais dire :
si le moteur de recherche ne cherche que dans les noms des éléments alors il ne sera guère utile pour trouver des données d'article pas directement visibles depuis le panel des collections.
Donc je ne voulais pas dire que la fonction disparaîsse (à proprement parlé dans le code) mais qu'elle devienne inutile si elle cherche seulement dans le nom des éléments.

41 (edited by Nuri 2017-10-03 11:37:32)

Re: Nouveautés de la version de développement 0.7

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...

42

Re: Nouveautés de la version de développement 0.7

Revision: 5061
Author:   scorpio810
Date:     2017-10-03 14:11:28 +0200 (Tue, 03 Oct 2017)
Log Message:
-----------
Add new field Name of provider,
rename fields,
update *TS files

43

Re: Nouveautés de la version de développement 0.7

scorpio810 wrote:

ajouter une nouvelle variable "Name provider"

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

44

Re: Nouveautés de la version de développement 0.7

Nuri wrote:
scorpio810 wrote:

ajouter une nouvelle variable "Name provider"

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

C'est pas grave, tu peux tricher dans la traduction.

45

Re: Nouveautés de la version de développement 0.7

Avec cette évolution: comment envisagez-vous la bibliothèque désormais ? Elle sera uniquement composé de symbole de base sans référence fabricant, ou allez-vous intégrer les symboles "référencés fabricant" ?

46

Re: Nouveautés de la version de développement 0.7

Tout dépend du symbole, il est clair qu'on ne va pas référencer dans la collection commune toutes les marques et références de contacteur, contact d'organe de commande, etc, mais les éléments constructeur spécifiques devraient profiter de ces nouvelles informations,exemple carte PLC de marque X et de type Y, variateur de marque X et modèle Y..

Apres chacun pourra créer suivant ses besoins et le matériel qu'il utilise et dont il dispose, de ses propres symboles avec leurs références pré établies dans les collections utilisateurs.

Il est clair qu'avec les évolutions faites depuis la version 0.6 il est dorénavant possible d’imaginer incorporer un très très grand nombre d’éléments dans les collections sans que la consommation mémoire augmente ou que l’expérience utilisateur en soit dégradée ou nécessite une workstation élitiste.

C'est vous tous qui faites ce que QET est et sera !  par vos remarques, suggestions, idées, votre talent pour dessiner et enrichir la collection, vos traductions, votre participation au développement par des patchs, bouts de codes, vos rapports de bugs, etc.

47

Re: Nouveautés de la version de développement 0.7

scorpio810 wrote:

Tout dépend du symbole, il est clair qu'on ne va pas référencer dans la collection commune toutes les marques et références de contacteur, contact d'organe de commande, etc, mais les éléments constructeur spécifiques devrait profiter de ces nouvelles informations,exemple carte PLC de marque X et de type Y, variateur de marque X et modèle Y..

Apres chacun pourra créer suivant ses besoins et le matériel qu'il utilise et dont il dispose, de ses propres symboles avec leurs références pré établies dans les collections utilisateurs.

Et les partager sur le forum !

48

Re: Nouveautés de la version de développement 0.7

Sur le forum, mais pas que, je pense plus au serveur web ou toute l'interface avait été mise en place par Xavier au tout début de QET dans le but de permettre à tout à chacun le moyen de proposer et partager de nouveaux éléments aisément.

De permettre aussi la consultation des bibliothèques d'éléments par catégories, par upload, etc.
Pouvoir aussi visualiser chaque élément (même si la conversion XML -> SVG n'est pas encore parfaite et ne tient toujours pas compte de la rotation des textes, etc), voir ou étudier le fichier XML source de l’élément.
Faciliter le téléchargement sous forme d'archives ZIP par collection, catégorie ou par un élément séparément.

49

Re: Nouveautés de la version de développement 0.7

Houla, je vois que vous avez beaucoup d'idées....
C'est incroyable, à chaque fois que je fais un petit truc qui arrange la vie (ex : des textes dynamiques), mais sans aucune ambition, vous trouvez toujours le moyen de transformer ça en une nouvelle fonctionnalité poussée.... nomicons/laughing
Bref, à la base c'est juste des textes dynamiques qui peuvent avoir comme source de texte une information de l'élément. Puis j'ai poussé ça dans l'éditeur d'élément et donc en même temps, les infos d'élément, afin que les textes dynamiques disposent des même fonctionnalités dans l'éditeur de diagramme et d'élément.
Il s'agit des mêmes infos que celles qu'on trouve déjà dans l'éditeur de diagramme, depuis un certain temps.

Je ne suis pas contre ce que vous proposez, bien au contraire, mais pour le moment laissez moi finir les textes dynamiques (il reste encore pas mal de travail sur ce sujet).
Je pense qu'il serait bien d'ouvrir un nouveau topic pour parler de ça, car ça devient un gros morceau nomicons/smile.
Il faut pas oublier non plus, que certains veulent des textes multilingues et donc, aussi bien dans le code qu'à l'utilisation, ça fera parti intégrante des informations d'élément. Bref, il y a matière à cogiter pour faire ça bien.
Ne reproduisons pas les mêmes erreurs qu'auparavant, implémenter un truc trop vite et de me retrouver à faire du code pour être rétrocompatible, des fois pour la même version de développement.

scorpio810 wrote:

   
Tout dépend du symbole, il est clair qu'on ne va pas référencer dans la collection commune toutes les marques et références de contacteur, contact d'organe de commande, etc, mais les éléments constructeur spécifiques devrait profiter de ces nouvelles informations,exemple carte PLC de marque X et de type Y, variateur de marque X et modèle Y..

Pour continuer le texte de Laurent, ce que je suis en train de faire en ce moment et au vue des améliorations envisageable, n'est pas une finalité et ne rendra pas une bdd d'article inutile. Car justement, pour tous les composants électriques standards (ex : un contacteur) aucune info ne sera renseignée dans la définition de l'élément, en revanche quand l'utilisateur renseignera les données une fois l'élément posé sur le folio, une bdd sera très utile.
Donc n'allons pas trop vite en besogne pour éviter les bourdes.

Pour finir, avec toutes les fonctionnalités que vous souhaitez, voyez plutôt ce qui existe comme un bac à sable, et donc sujet à de gros changement durant le développement, avec sûrement des choses non rétrocompatible (je parle de choses pendant le dev).
Mais expérimentez, torturez le truc, dériver ce pour quoi c'est fait actuellement et après tout ça, reportez ce qui va/ne va pas, les améliorations "incontournable" etc.... et ensemble on devraient crée un bon truc nomicons/smile   

Bon après ce long post, je vais au boulot.

50

Re: Nouveautés de la version de développement 0.7

Nuri wrote:

Ca sent le script batch à plein nez, mais je sais pas si je saurai faire nomicons/getlost

Tu voulais dire bash, tu auras plus de facilité avec une macro LO, xmlstarlet, sed, awk perl, qu'un simple script bash.