Search options (Page 27 of 33)

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?

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.

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

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

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.

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

Techniquement oui, mais pour quel raison?

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

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.