Nouveautés de la version de développement 0.7 (Page 2 of 23)

Plop !

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

Joli ! Nuri va être comme un dingue !

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

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

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

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.

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.

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

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

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

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

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

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.

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.