626

(8 replies, posted in Chez nous les Pros)

Effectivement kate est vraiment un excellent éditeur de texte (et même plus).
Je suis sous gnome shell et j'adore gedit, mais il est complètement à la ramasse comparé à kate.

scorpio 810 wrote:

Pour l'instant la seule variable pouvant être ajouté est le label, rentrer une formule à la main ne fonctionne pas encore.

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

Nuri wrote:

Autre question qui me turlupine depuis l'arrivée des textes dynamiques :
une fois que tu auras converti les textes tagués (label...) en textes dynamiques, quelle sera alors la configuration d'affichage par défaut lorsque je fais un tiré/déposé d'un élément sur le folio ?
En d'autres termes :
est-ce qu'il faudra cliquer sur [+], choisir "information de l'élément", puis choisir "label" pour avoir le droit de voir le repère du composant sur le folio ?

Le texte dynamique aura comme source de texte "label", pas besoin de refaire la manip.
Pour l'instant, ce n'est qu'une ébauche, mais quand ce sera prêt, dans l'éditeur d'élément, tu pourras paramétrer les textes dynamiques avec exactement les mêmes propriétés que celles disponibles sur l'éditeur de diagramme.
Une fois l'élément posé sur le folio, les textes dynamiques auront les propriétés définies depuis l'éditeur d'élément.

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.

630

(8 replies, posted in Chez nous les Pros)

Ne pas confondre les développeurs et les gros éditeurs de logiciels, qui eux, ne s'embête pas à rendre leurs produits compatible pour d'autres OS, qui représentent un petit %.

Nuri wrote:

Merci !
Quelque part, ouais, t'es un génie car pour bouffer, et surtout digérer, du C++ comme te le fais, chapeau 20x20

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

Nuri wrote:
Galexis wrote:

Autre question, les textes dynamiques ne respectent pas la même logique pour le positionnement

Il me semble que les textes fixes et les textes dynamiques n'utilisent pas le même point de référence.

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.

galexis wrote:

Il y a effectivement un comportement bizarre, surtout sur la fenêtre des texte composé, qui apparaît un peu quand elle veut...

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.

Nuri wrote:

Quelques petits souhaits de ma part :
1.
Quand on veut ajouter un texte dynamique depuis le widget "Propriétés de l'élément" en cliquant sur le bouton [+], ce serait bien que le QTreeMachin soit totalement ouvert (déroulé) par défaut, ca éviterait 3 clics de souris inutiles.
2.
Est-ce possible de faire bouger les textes "en temps réel" avec les nouveaux champs X et Y ?
Pour l'instant, les textes changent de position seulement quand on valide la nouvelle valeur de X ou Y.

Tel un génie nomicons/cool  tes souhaits sont exaucés.

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" nomicons/cool
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 nomicons/smile

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.

scorpio810 wrote:

Je pense qu'une recherche et filtre dans le tree widget serait pas une mauvaise idée, vous en pensez quoi ?

Juste rechercher le "texte" afficher par un champ texte ?

galexis wrote:

Dans l'éditeur d'élément, il y a 3 types de textes (texte, champs texte et texte dynamique): les trois sont convertit en texte dynamiques?

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 nomicons/grin

Re-searcher wrote:

@ Joshua ,
Vous devez voir le " texte " dans un sens différent.
Vous avez un grand programme qui n'est pas écrit par vous-même.
Mais aussi par d'autres personnes.
Il faut aller chercher une variable dans le grand programme.
Mais on ne sait pas où cela se trouve.

Ok je n'avais pas compris qu'il était question du code.
Pour ma part, je développe QET avec QtCreator, qui dispose d'un outil de recherche assez puissant (par mots, mais aussi recherché les classes, fonctions de classe, enum etc....).

@Nuri
Ok je comprend, effectivement ce serait un belle outil à ajouter à QET => todo list.

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

Le commit N°5084 règle (normalement) le problème.

Oui, j'ai repéré le problème (sans même ouvrir le code nomicons/cool ), 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".

Mise à jour du premier post :

Éditeur de diagrammes :
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.
À l'heure actuelle, seul les textes ne comportant pas de tagg sont convertis.

Étant donné que les conversions d'une chose en une autre, n'est jamais sans risque. Je conseille à tout le monde de faire une copie de leurs projets, avant de faire une sauvegarde avec la version de QET, qui apporte cette modification.
N'hésitez pas à rapporter tous problèmes rencontrés suite à ça.

Nuri wrote:

Et l'idée des X et Y pour les champs dynamiques ?

Oui y'a pas de problème nomicons/smile

En fait le freeze, correspond à la mise en place des Xref.
Le dialogue avec la barre de progression affiche uniquement le chargement des folios, une fois à 100%, les Xref ne sont pas encore crée.
J'avais regardé pour afficher ça dans la barre de progression, mais ça demandais quelque remaniement que j'ai préférer repoussé, et le multithreading un énorme travaille.

Il est possible que le freeze soit plus court avec le ItemIndexMethod réglé à "NoIndex" au lieu de "BspTreeIndex" (je vous laisse juger le avant/après).
À noter que le temps de freeze est proportionnel à la taille du projet.

scorpio810 wrote:

D’après les recherches de Joshua, le bug des conducteurs fantômes et qui a nécessité de revoir pas mal de code serait fort probablement lié a un bug Qt, faudra étudier en profondeur le changelog Qt 5.9.2.

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 :

I had this issue and it was a real pain to fix it. Besides the crash, I was also having "guost" items appearing on the screen.

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

Nuri :
Non il n'y a pas de précaution particulière à prendre, la seul chose comme dit dans mon précédent post, c'est que les informations/données d'élément risque de pas mal bouger vue les demandes que vous m'avez faites et il y a aussi l'histoire des traductions (car pour bien faire, il faudrait rendre tout les textes traduisible, et il n'y a pas que les éléments qui sont concerné).
Donc ce morceau la peut être plus ou moins cassé en cours de dev, mais c'est tout. Pour résumer, comme d'habitude nomicons/smile.

Oui l'éditeur d'élément convertie déjà les anciens textes en texte dynamique, sauf les textes avec un tagg, mais je compte bien que eux aussi y passe à terme.

-La seconde étape : lors d'un drag/drop d'un élément sur un folio, convertir les champ texte présent dans la définition de l'élément en champ texte dynamique (totalement transparent pour l'utilisateur).

-la troisième étape : pour les éléments déjà présent sur un folio, convertir les anciens champs textes en champ texte dynamique (aussi totalement transparent pour l'utilisateur).

-Et l'étape final, supprimer le code des anciens textes.

Si vous avez bien suivi, cela veut dire, que même si vous créez 100 textes dynamiques dans l'éditeur d'élément, ce même élément une fois posé sur un folio peut avoir 0 texte dynamique si vous les supprimés, ou alors 200 si vous en rajoutez, bref l'utilisateur aura la total maîtrise des textes d'éléments.

À l'heure actuel, lors de la création d'un élément je vous conseil d'utiliser les nouveaux textes dynamique (mais il faudra quand même ajouter un ancien champ texte avec le tagg label) au lieu des anciens, pour les raisons suivantes :
-Il faut tester nomicons/devil
-À terme il n'y aura que des textes dynamique, donc ça évitera les conversions potentiellement hasardeuse.
-Si vous vous contentez de choisir comme source de texte "texte utilisateur", par définition ce "mode" n'est pas impacté par les information/donné d'éléments, donc ne devrais pas être cassé par la suite.

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.