Search options (Page 26 of 33)

Ok donc ce serais mieux si le combo box proposais toute les variables, même si elles ne sont pas renseignées.

Autrement dernier commit : il est possible d'ajouter un cadre autour des nouveaux textes.

Heu si, toutes les variables sont dispo, le combo box ne te propose que les variables des champ déjà renseigné.

Hop petite amélioration de la GUI,
les listes déroulante sont plus naturel.
Le dialogue pour éditer les champs composé a le focus lors de sa création = plus besoins de cliqué dessus, vous pouvez directement écrire.

Arrête, je vais prendre la grosse tête, de plus Qt facilite bien les choses.

Oui c'est bien ça.
Par défaut (Qt) le point d'origine est le coin supérieur gauche, avec les textes de QET, celui-ci a été déplacé au milieu du coté gauche.
Du coup il est a réévalué quand on change de taille de police, saut à la ligne etc....
J'ai préféré laisser comme c'est par défaut, car implique moins de code, et ne change rien à l'utilisation.

Pour le problème des textes, je n'ai pas réussi à le reproduire.
Vous avez une petite procédure.

Pour les divers comportement des widgets dans l'arbre des textes d'élément, faut que je peaufine tout ça, mais c'est pas toujours simple.

Tu est sure qu'elle apparaît quand elle veut ?
En fait le truc est un peu vicieux, quand le dialogue s'ouvre il faut cliquer dans le champ prévu pour écrire, si tu clic ailleurs le dialogue perd le focus, ce qui est interprété comme la fin de l’édition du dialogue, du coup celui-ci se ferme.
J'ai même déjà vue d'autre truc chiant, que je n'ai pas résolut pour l'instant.

Cher utilisateur de QET, je viens à toi, afin de demander ta précieuse aide. Mais en prérequis, il faut que tu ais déjà fais mumuse avec les "nouveaux textes dynamiques"
Comme je l'avais déjà mentionné dans les précedents posts, les "anciens" textes avec tagg, ne sont (pour l'instant) pas convertis en texte dynamique, et voila pourquoi :
Actuellement, avec les anciens "textes" dans l'éditeur de schéma, dès lors que le commentaire de l'élément est renseigné et que celui-ci est coché, le commentaire apparait dans un encadré sous le label ou Xref de l'élément en question.
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 me pose donc la question suivante, faut-il garder ou non, les commentaires "automatiques" dans un encadré ?
Dans le cas ou la réponse serait non, la nouvelle façon de faire serait d'ajouter un "nouveau texte dynamique" avec comme source de texte "commentaire".

Je vous laisse débattre

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.
L'avantage par la suite, serait d'ajouter les fonctionnalités suivantes : Alignement gauche/centré/droite des textes d'un groupe.
Attention, je n'ai encore rien codé sur ce sujet et je ne sais pas encore la difficulté du truc. Donc je ne vous fais aucune promesse.

Non,
texte = c'est un champ texte avec aucune interaction dans l'éditeur de schéma, c'est une partie de dessin de l'élément. Donc n'est pas converti, et ne le sera jamais.

Champ texte = oui ils sont convertis, à l'exception de ceux qui on un tagg pour l'instant.
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".

Champ dynamique = ba pas de conversion

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

Oui, j'ai repéré le problème (sans même ouvrir le code ), quand les taggs de textes sont arrivés dans QET, tous les éléments de la collection officielle n'ont pas été taggé (vous imaginez le nombre d'éléments à se tapper à la main...) du coup pour palier à ça, quand on dépose un élément qui n'a pas de texte avec le tagg "label", on prend le premier texte de l'élément et on lui assigne d'office le tagg "label", c'est le cas pour les reports de folios......
Et comme maintenant, les textes sans tagg sont convertis en texte dynamique, vous connaissez la suite.....
Je regarde pour corriger ça le plus rapidement possible.

Il y a longtemps que je voulais faire un truc, mais ce coup-ci, il va falloir le faire :
Dans l'éditeur d'élément créer une fonction qui met à jours tout un répertoire d'éléments, afin que ceux-ci soient conformes avec les dernières spécifications.
Cela évitera un travail toujours plus long (la collection s'agrandit sans cesse) de mise à jours "à la main".

Oui y'a pas de problème

Oui, voici les différents liens qui en parlent :
https://forum.qt.io/topic/71316/qgraphi … removeitem
https://stackoverflow.com/questions/384 … item-class
http://www.qtcentre.org/archive/index.php/t-33730.html
http://tech-artists.org/t/qt-properly-r … items/3063
Dans l'un des forums, il est clairement dit :

Plusieurs choix m'étaient disponibles, j'ai choisi celui qui me semblait le plus propre, c'est-à-dire d'appeler la méthode
SetItemIndexMethod avec comme argument "NoIndex" au lieu de "BspTreeIndex".
Actuellement, la correction est disponible uniquement sur la 0.7 dev.
Si il n'y a pas de retour négatif, la correction sera retro-portée sur la 0.6.
D'après la doc Qt, il ne devrait pas y avoir de ralentissements, voir peut-être même le contraire car "NoIndex" est plus adapté aux scènes avec des items qui sont souvent ajoutés, déplacés ou supprimés.
http://doc.qt.io/qt-5/qgraphicsscene.ht … ethod-enum

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

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    

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

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

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

Pourquoi cette fonction viendrais à disparaître?