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

@ Laurent :

j'utilise pas la 0.7 pour mon boulot, donc j'ai pas d'expérience réelle avec.
Difficile de te donner une impression juste en faisant quelques tests et essais de temps en temps avec la 0.7 compilée depuis le trunk.
Sur mon système, j'ai laissé la 0.6 pour travailler, ca me semble plus sûr en attendant que les textes dynamiques soient totalement opérationnels, testés et traduisibles.

De toute facon, depuis le passage au multi-threading pour charger le logiciel et les collections, le démarrage de QET est vraiment rapide et, là aussi, c'est difficile de sentir une amélioration de la rapidité d'éxécution.

Autant pour moi ! j'ai oublié de préciser sur les derniers paquets Windows non XP_Vista.
Autant QET se lance en un éclair sur ma Debian, a peine le temps d'entre voir la progressBar ... alors que sur Windows on a même le temps d'admirer le splash screen et la progression de la progressBar, donc je fais quelques tests avec le cross-compilateur voir si on peux améliorer quelque peu le multithreading de QET sous Windows.

@ Galexis : merci du retour. 

En fait quand, je fais mes schémas, je crée ma nomenclature et ma liste d'entree sortie automate avant pour pouvoir commandé le materiel.
 Je me retrouve avec un fichier excel ou j'ai déjà tous mes labels references et rôles de chaque element ainsi que la marque sur mon écran de droite. ( Via VBA, je genere des image de 25 lignes de nomenclature que je colle directement dans q elec, plus malin plus rapide)
quand je pose mon symbole je clique dessus pour afficher la fenêtre propriété information puis je copie colle mon label. 
Dans le champ commentaire j'y met le role et la reference, ( en fait pour un var mx2 omron le symbole est le meme pour différente reference...; idem pour les var 1S etc et pour la plupart des NX IO.
Donc du coup je trouvais ça plus rapide de copier directement dans le champ description textuelle et reference en positon x y que d'aller dans l'onglet texte.
Recréer un symbole a chaque fois que j'ai une reference qui change pour un symbole identique, c'est un peut lourdingue... ( le reference je l'affiche pour les cableurs plus simple pour eux, moins de boulette)

Article number

Je serais présent (en [s]touriste[/s] visiteur) samedi et peut-être aussi dimanche au capitole du libre 2017 à Toulouse (INP-ENSEEIHT).
Si certains sont dans les parages ce W.E ça peut-être une occasion de se rencontrer et discuter de QET . 
https://linuxfr.org/news/capitole-du-li … 9-novembre

c'est moi qui ai proposé de changer "description" en "numéro d'article", etc.
Pourquoi, me diras-tu ?
Eh bien justement parce que les intitulés des différents champs n'étaient pas assez clairs.
"description", ca veut dire un peu ce qu'on veut... pour certains ce sera "disjoncteur machin-chose...", pour d'autres, ce sera "FAZ-B13/1" ou que sais-je d'autre...
Maintenant, je pense que les intitulés sont clairs et nets, ils ne porteront plus à confusion.
Je pense que ce genre de précisions deviennent importantes maintenant car Joshua implémente, avec les nouveaux textes dynamiques, un système avec lequel on peut rentrer des infos textes directement lors de la création des éléments, typiquement pour décrire de quel matériel il s'agit concrètement et ainsi pouvoir construire au fur et à mesure des collections "d'articles constructeur".

Ce que je vois pour l'avenir, c'est que ces collections, que chacun fait pour l'instant gentillement dans son coin, ne seront visiblement pas compatibles entre-elles car justement les intitulés des champs d'informations portaient à confusion.
Si dans un avenir assez proche on (je ?) développe le site web de QET pour pouvoir partager plusieurs collections "d'articles constructeur", ce serait bien que dans "numéro de commande", par exemple, tu trouves effectivement un numéro de commande et pas un truc qui n'a rien à voir... Sinon, quel est l'intérêt de mettre des collections en ligne, s'il faut repasser sur le boulot des autres avant de pouvoir s'en servir ?

Celle-la aussi je l'attendais
C'est clair que ca va être le gros basar, et la fin n'est pas proche...
C'est pour cette raison que j'avais proposé à Laurent et Joshua de rajouter une ligne dans l'export en csv. Cette ligne servirait d'en-tête universel où chaque colonne serait identifiée par un numéro ID unique en plus des descriptions "folio", "numéro d'article", etc situées une ligne plus bas. De cette facon, les scripts et macros de chacun chercheront les colonnes en fonction d'un ID invariable et non plus une chaîne de caractères qui change de place au gré des évolutions du logiciel (et qui change aussi quand on édite la nomenclature dans une autre langue que la sienne)
Ca donnerait un truc du genre (les ID sont dans la ligne jaune) :

C'est une question de perception, je les trouvais au contraire beaucoup plus clairs avant.
Pour moi ni le numéro de commande, ni le numéro d'article ne correspondent à l'ancienne "référence fabricant":
- un numéro de commande serait: le numéro de la commande interne à l'entreprise, qui a permis l'achat du matériel
- un numéro d'article: un code pour la gestion du stockage sur étagère.
Quelle est la nouvelle appellation pour désignation ? Pour moi, il n'y a aucune équivalence maintenant.
Ce qui est pénible au delà qui nouvelles appellations au sens discutable, c'est de devoir reprendre les vieux projets et de déplacer les informations dans les "bons" champs.

@ galexis :

numéro de commande : le numéro que le SERVICE VENTE du FABRICANT du matériel attribue à ses articles.

numéro d'article : le numéro que le FABRICANT du matériel attribue à ses articles. Souvent, le numéro d'article ne change pas quand il y a des petites évolutions (par exemple update firmware) alors que le numéro de commande si car le service vente n'a pas le droit de se planter quand il envoie du matos chez le client.

numéro interne : le numéro que l'on attribue soi-même en interne dans l'entreprise ou l'organisation dont on fait partie. Typiquement, le numéro interne, c'est pour caser le numéro issu des progiciels de gestion intégrée (genre SAP, ORGAMAX et cie.).

ex-désignation = description textuelle, où on écrit dans sa langue ce que le machin est (disjoncteur machin-chose...). C'est á mon avis le seul champ qu'il faudrait pouvoir traduire. Les autres sont invariables car le marché est global et planétaire.

Personnellement je ne suis point concernés par ça !, quand je reprend des schémas, affaires, c'est entre les pannes, mon travail consiste a vérifier, annoter, corriger les anciens schémas de nos installations et tout redessiner et remettre au propre sous QET.
Il m'est impossible de renseigner chaque article que j’inclus dans mes schémas encore moins le numéro d'article magasin ..., déjà parce qu'en magasin ou sur les machines toutes les marques constructeurs sont représentées, et qu'il ait souvent facile de remplacer la pièce marque x par la marque y sur une panne ou dans l'urgence...
De plus ça me prendrait des mois voire des années pour obtenir ce type de schémas avec nomenclature complète avec le peu de temps libre entre les pannes dont je dispose ....

Si au lieu d'avoir :
"Numéro d'article", on avait "Numéro d'article fabricant"
et
"Numéro de commande", on avait "Numéro de commande fabricant"
Est-ce que cela supprimerait les confusions et contenterait tout le monde ?

PS
Les groupes de textes avancent

Le voici dans l'état actuel: je n'ai pas testé suite aux changements d'appellations, mais cela ne doit pas changer grand chose, si ce n'est les entêtes de colonnes qui ne correspondent pas à QET ... ;-) Seul sont gérés les éléments dont le champs référence est rempli.

Je ne me sert pas des d'entêtes de colonnes pour la génération de la nomenclature, uniquement des numéros de colonnes de tableau. Que ce soit en clair me va bien, car comme cela je n'ai pas trop à chercher les données.