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.

Aleksandr,
Crash fixed.
Revision: 5060
Author: blacksun
Date: 2017-10-03 10:54:58 +0200 (Tue, 03 Oct 2017)
Log Message:
-----------
Fix crash when user try to move a non movable item.

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?

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

Le nouveau widget à été créé afin d'afficher plus d'information et être plus clair, mais il vrai qu'il faut faire plus de clic pour lier deux éléments.
Si la disposition des informations du nouveau widget ne vous convient pas, il vous suffit de déplacer les entête et/ou les agrandir puis de faire un clic droit sur l'entête et dans le menu contextuel choisir sauvegarder la disposition. Ainsi la disposition du widget restera comme vous l'avez choisis.

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

galexis wrote:

La 0.7 existe en version portable:
https://download.qelectrotech.org/qet/builds/nightly/

La 0.6RC2 aussi (ready to use)
https://download.qelectrotech.org/qet/b … 7-08-01-1/

jmvulliamy wrote:

Un grand BRAVO pour ce logiciel : 10 élèves pendant 5h. sans aucun problème.

Votre produit est tout à fait adapté à mes besoins et je me réjouis de le voir évoluer. En cas d'intérêt, c'est volontiers que je remonte les problèmes rencontrés et mes besoins spécifiques.

Merci nomicons/smile,
oui nous apprécions toujours les retours des utilisateurs (Bug, choses qui vont bien, d'autres qui ne vont pas, souhait d'évolution, même mineur) ça nous permet d’amélioré QET, et de l'adapter le mieux possible au cas d'utilisation réel.

jmvulliamy, as tu testé avec la version 0.6 ou 0.7dev.

Bon je vient de regarder le problème, les textes fonction tension/protocole apparaissent bien, sauf dans certains cas comme par exemple :
posé un renvoie + élément, mettre un conducteur entre les deux, remplir fonction tension, le renvoie est bien mis à jours.
posé un autre + élément + conducteur, liée le renvoie au premier, la ça ne fonctionne pas, il faut édité un conducteur (du potentiel pas forcement celui liée au renvoie qui ne fonctionne pas) et la c'est mis à jour.

Salut Galexis,
non je pense pas que ce soit normal. Je vois pas pourquoi la fonction ou tension ne serai pas afficher si le numero n'existe pas.
Y'a eu des changements dans la 0.7dev mais rien la dessus, donc il y à de forte chance que la coquille soit présente dans la 0.6.
Je regarde ça dès que possible.

galexis wrote:
Joshua wrote:

Il s'agit de l'élément auquel appartient le texte en question.
Ainsi, chaque champs remplis dans l'onglet information, est disponible en tant que "sources du textes -> information de l'élément" pour le texte dynamique.
À terme, cela sera valable pour les éléments maître / simple / bornier, les renvoies seront limité (étant donné qu'il ne s'agit pas d'un composant réel) et les esclaves iront cherché les infos de l'élément maître auquel ils sont liée.

Bonsoir Joshua,
à quoi va servir le champs "taag" ? A créer des propriétés perso ?

-Pour l'instant le champ "tagg" ne sert à rien, mais je l'ai mis afin que les utilisateur puisse poser un tagg perso, qui potentiellement pourrais être exploiter à l'avenir.

Sera-t-il possible dans un élément simple, d'aller chercher le label, la position ou autre info d'un autre élément simple ?

Techniquement oui, mais pour quel raison?

galexis wrote:

Bonjour,
j'utilise la ReadyToUse 0.7svn5016, et je me suis aperçut qu'il n'est plus possible de déplacer une sélection multiple dans l'éditeur d'élément. La main qui apparaît redimensionne.

J'ai corrigé un truc, pas un problème de redimensionnement, mais essais quand même, peut être que ça réglera ton problème.

Sur l'éditeur de schéma, pour les petits conducteurs, il est difficile d'ouvrir les propriétés par double clic: les boules bleues gênant le clic.

Y'a toujours la solution de Laurent, mais j'ai quand fait une modif, maintenant quand tu double click sur une boule, sa ouvre les propriétés du conducteur.

Bonjour jmvulliamy,
galexis a bien expliqué les choses, fonction et tension/protocole servent pour les reports de folios, et indique la fonction ou tension/protocole du potentiel électrique liée au renvoie.
Pour l'onglet "texte" c'est normal que tu ne le trouve pas, il n'existe pas dans la version 0.5.
Je te conseil d'utiliser la 0.6 RC2 qui sera très rapidement la prochaine stable, ou alors si cela ne te dérange pas d'utiliser une version de développement, de prendre la 0.7dev qui actuellement est très proche de la 0.6, à l'exception des nouveaux textes d'éléments, voir ici https://qelectrotech.org/forum/viewtopic.php?id=1092

Pour le coup, ce n'est pas liée au xml (Qt écrit les attributs dans l'ordre qui lui chante, en revanche les éléments xml sont bien inséré dans l'ordre), c'est juste que lors de l'enregistrement, on "prend" chaque formes puis on les enregistres dans le XML, seulement quand on les "prend", elles ne sont pas forcement dans le même ordre. http://doc.qt.io/qt-5/qgraphicsscene.html#items

En fait on enregistre les coordonné X.Y dans le XML mais pas Z.
Je met dans la todo list l'édition de la coordonné Z plus l'enregistrement dans le XML.

Effectivement c'est un problème qui à déjà été rapporté.
Il n'y a (actuellement) pas moyen de gérer la position en profondeur, et comme tu l'as remarqué, lors de l'enregistrement, les formes ne sont pas enregistrer dans le même ordres, ce qui provoque lors de l'ouverture du projet des profondeurs différente.
En l'état actuel des choses, je te conseil de crée un élément, au lieu de "dessiner" depuis l'éditeur de schéma.

Il s'agit de l'élément auquel appartient le texte en question.
Ainsi, chaque champs remplis dans l'onglet information, est disponible en tant que "sources du textes -> information de l'élément" pour le texte dynamique.
À terme, cela sera valable pour les éléments maître / simple / bornier, les renvoies seront limité (étant donné qu'il ne s'agit pas d'un composant réel) et les esclaves iront cherché les infos de l'élément maître auquel ils sont liée.

MAJ le 08/03/19

Bonjours,
J’énumérais sur ce topic les nouveautés apportés à la version de développement qui sera la future version 0.7.
Seront présentes uniquement les nouvelles fonctionnalités disponibles pour l'utilisateur.
Tout autre chose, tel que les bugfixs, remaniement de code et autres qui n'apporte rien de nouveau pour l'utilisation de QET ne seront pas mentionné ici, à quelques rares exceptions.
Ce topic n'a pas pour vocation d'être une release note (car ne sera pas exhaustif), mais aidera à visualiser rapidement les évolutions.


Éditeur de diagrammes:
#Le panneau latéral (dock widget) d'édition de la sélection courante, peut maintenant être utilisé pour éditer les textes indépendant.
Il est possible d'éditer un ou plusieurs textes en même temps.

#Il est possible de choisir la police des textes indépendant.

#Plusieurs formes simple peuvent être édité en même temps depuis le panneau latéral

#Lors d'une recherche dans le panel d'élément, en plus du nom, les éléments sont aussi filtrer par leurs informations

#Deux nouvelles variables pour les cartouches, permettant d'afficher le numéro des folios précédent et suivant.

#Fonction rechercher remplacer des textes (textes indépendant, éléments, conducteurs, folios)

#Possibilité de définir le chemin des collections d'éléments (commune et perso)

#Possibilité d’arrondir les coins d'un rectangle.

#possibilité d'ajouter/supprimer les points d'un polygone.

# Conducteur bicolor : les conducteurs peuvent maintenant être dessiné avec deux couleurs

#Texte de conducteur : Il est maintenant possible de configurer la position d'un texte de conducteur haut/bas/gauche/droite par rapport au conducteur.

[s]# Petite exception à la règle cité plus haut : Le code des poignées de redimensionnement a été presque intégralement repensé.[/s]
[s]concrètement cela ne change rien pour l'utilisateur (les poignées ne sont plus des carrés mais des ronds).[/s]
[s]Cependant, je me permet de le mentionné, car l'ancien code provoquais des crashs plus ou moins aléatoires (dont beaucoup d'utilisateurs en ont fait les frais), mais prévisibles dès lors qu'il y avais des conducteurs ou shapes fantôme après leurs suppressions. Par le passé le problème avait été minimisé, suite à quelques bidouilles dans le code, mais étais toujours présent.
[/s]La correction a été porté sur la 0.6


# Il est maintenant possible d'ajouter un champ texte à un élément directement depuis le diagramme.
Pour cela cliquer sur un élément puis rendez vous dans le widget de propriété, un nouvel onglet "texte" permet d’accéder à cette nouvelle fonctionnalité.
Les textes peuvent avoir différentes "sources de texte" :
-un simple texte que vous écrivez vous même.
-une information de l'élément, par exemple le nom du fabricant.
-Le mélange des deux.

#possibilité de grouper plusieurs textes d’un même élément ensemble, et d'alignés les textes d'un groupe (gauche / centre /droite)

#Les configurations de textes et de groupes de textes peuvent être exporté et importé, évitant ainsi d'avoir à recrée toujours les même textes et groupes pour plusieurs élément.

#Conversion ancien -> nouveau texte :
-Lors d'un glisser/déposer d'un élément depuis la collection d'éléments vers le folio, tous les "anciens" textes sont convertis en texte dynamique.
-Lors de l'ouverture d'un projet, tout les "anciens" textes d'éléments, des éléments déjà présents sur les folios sont convertis en texte dynamique.
À noter que pour les deux cas, tout est automatique, l'utilisateur n'a rien à faire.

#Dialogue de récupération du/des projet/s suite à un crash.

#Sauvegarde automatique (désactivable)

#La coordonné Z des items présent sur les folios est éditable.

#Un nouvel outil : le multi-collage
Permet de coller plusieurs fois une sélection en une seul fois.
Une option permet de continuer la numérotation des éléments et conducteurs coller.

#Lorsqu'un éléments sur lequel est raccroché plusieurs conducteur sur une même bornes est supprimé, le potentiel électrique n'est plus détruit.
Une vidéo vaut mieux qu'un long texte.

Éditeur d'éléments :
#Possibilité d’arrondir les coins d'un rectangle.

#possibilité d'ajouter/supprimer les points d'un polygone.

#Les nouveaux champs textes (dynamique) sont disponible aussi dans l'éditeur d'élément.
Les "anciens textes" sont convertis en nouveaux champs textes (dynamique) lors de l'ouverture d'un élément dans l'éditeur d'élément.

LETARTARE wrote:

Pour supprimer le dernier message dans la console lors d'une fermeture de Qet

External WM_DESTROY received for  QWidgetWindow(0x3910068, 
      name="AboutQETClassWindow") , parent:  QWindow(0x0) , transient parent:  QWindow(0x0)

Dans 'void QETApp::aboutQET()'  inverser les deux dernières lignes comme ceci :

// affiche le dialogue puis évite de le lier à un quelconque 'widget' parent
    about_dialog_ -> setParent(0, about_dialog_ -> windowFlags());
    about_dialog_ -> exec();

ceci fonctionne sous VISTA.

Cordialement

Corrigé, merci du retour.

Nuri wrote:

oui, les conducteurs auto ne marchent que lorsqu'un seul et unique élément est déplacé.
Je ne sais pas si Joshua a prévu d'étendre la fonction à plusieurs éléments avant la sortie de la version 0.6.
Il se peut que cela demande une certaine dose de travail... mais comme d'hab... j'en sais rien !

Non ce ne sera pas pour la 0.6 (pas de nouvel fonctionnalité, uniquement des bugfix jusqu'à la sortie)
A l'époque, j'avais regardé pour le faire, mais ça demandais une bonne dose de travail, et un certain meli melo vis à vis de la pile d'annulation.
Cela dit je peut effectivement regarder à nouveau le sujet, avec peut être de meilleurs idées.

scorpio810 wrote:

Ce qui est dommage c'est que Runsys ai un peut lâché son projet de conducteurs intelligents capables d’éviter les obstacles/éléments sur leurs trajets.

Effectivement c'est dommage, surtout que pendant qu'il avançais sur les conducteurs intelligents, j'ai crée les conducteurs auto, et Il y a eu incompréhension (travail en doublon, et que je le court circuits) alors que les travaux était plutôt complémentaire.
La création des conducteurs et le chemin de ceux ci sont deux choses différentes.
De mon coté : Création auto des conducteurs = plus rapide pour l'utilisateur et évite le cotée répétitif.
De son coté : Chemin de conducteur plus intelligent = plus rapide pour l'utilisateur, dans le sens ou il n'a pas  reprendre à la main le chemin.

Je confirme le problème.
Avant le déplacement le texte n'est pas caler sur la grille (snap to grid).
Après une annulation du déplacement, le texte est repositionné à l'emplacement d'origine, mais avec l'option snap to grid d'active, ce qui provoque le décalage.
Je me penche sur ce problème.

Attention, ce comit ne corrige pas le problème énoncé plus haut.
Il s'agit d'un autre bug qui été passé entre les maille du filet.

Nuri wrote:

Est-il prévu de charger les projets en utilisant le multi-threading ?
Avec un CPU moderne, ca fait une sacrée différence !

Le chargement des projets n'a pas été crée avec l'idée d'être multi-threadé un jours.
Pour l'être, cela nécessite de revoir une bonne partie du code correspondant. C'est faisable, mais demandera une bonne dose de travail.

Félicitations aussi pour les derniers travaux réalisés fin 2016 / début 2017.
QET crash très peu en ce moment.

J'espère que mes dernier travaux diminuerons encore les crash. Je pense surtout au poignée de redimensionnement qui ont été quasiment entièrement réécrite.

May be a beginning of explanation : http://doc.qt.io/qt-5/qprinter.html#PrinterMode-enum
I have to see this, but there will be difficult because I haven't got a hdpi screen for test.

-The button "Find in the panel" work now.
-For the label, this is the good behavior.
If follow is unchecked, the label follow the rotation of the element.
if follow is checked, the label follow the rotation of the element, but stay in the same angle.
Thanks for report.

Pour le problème du crash, c'est réglé.
En revanche pour la collection qui ne se charge pas quand la fenêtre est détaché, il faut que je trouve une solution de contournement.