Commit 5117 / 5118.

Support initial des groupes de textes, cad.
possibilité de grouper des textes, sauvegarde des groupes dans le .qet, alignement des textes par raccourcie clavier (a,z,e).

Les fonctionnalités qui manque:
-un menu contextuel pour choisir l'alignement
-Gestion par la pile d'annulation
-possibilité de crée des groupes depuis l'éditeur d'élément.

Malgré le manque de certaine fonctionnalité, les groupes sont parfaitement utilisable.

Amusez-vous

Bonjour Mikael,
je suis le développeur de QElectroTech, je m’excuse de me présenter seulement maintenant (pas dispo).
Pour ton problème :
Logiquement tu as due faire en sorte que ton round rect sois enregistrer dans le .elmt (qui est un fichier xml).
Ensuite comme t'as indiqué Laurent regarde du coté de la classe custom element, où tu devras faire le travail inverse, cad, depuis la description xml de l'élément crée le "dessin" de l'élément, regarde en particulier les fonctions parse (rect, ellipse, arc etc...)
Je reste à ta disposition pour plus d'information.

Ok fixed in commit 5107.
Just wait for a new build

Cool vous avez trouvé la source du problème nomicons/cool 
Mais je vais quand même mener mon enquête afin d’arrêter ce vilain bug nomicons/devil

Le descriptif du problème est étrange. Mais je ne pense pas que cela vienne d'une version viellote de Qt.
Affaire à suivre...

Salut galexis, je n'ai pas réussi non plus à faire un crash.
Le simple fait de poser un report de folio "suivant" sur le folio suffit à planter qet ?
Tu utilise les reports de la collection officiel ?

Nuri wrote:

Mais si tu implémentes cela, penses à une chose : dès qu'on configure quelque chose (par exemple l'export csv), il faut pouvoir enregistrer les données de configuration quelque part sous forme de fichier (xml, texte ou autre, le format n'est pas très important pour l'utilisateur).

Je pensais bien faire ainsi

galexis wrote:

De mon point de vue, quit à passer du temps à développer, il vaut le passer sur autre chose que l'export qui a un pour but de favoriser les bidouilles : le but est quand même que QET fasse un jour tout ça nativement.

Je m'avance un peu, mais crée un petit dialogue pour configurer l'export ne me demandera pas trop de temps. De plus je pense qu'un export peut toujours être intéressant pour sortir une liste de matériels en dehors de QET.
Après je suis 100% d'accord avec toi que QET sache faire ça nativement.

galexis wrote:

est-ce qu'il est prévu de rendre réglage l'orientation angulaire des textes dynamiques ?

C'est déjà le cas. Tu veut dire dans le widget des propriétés?

Salut,
Je ne serais pas trop chez moi durant quelques jours, donc je n'ai pas encore regardé ton commit Nuri.
Comme je l'avais dit, je voudrais que la 0.7 soit une version de polissage et non une version avec de gros changement (vous allez me dire que les nouveaux textes ne sont plus trop dans la catégorie polissage....).
Entre autre je pensais reprendre l'export de la nomenclature.
Le format final du fichier serais le même (csv).
Ce que je voudrais faire, c'est créé un dialogue dans lequel l'utilisateur pourra choisir quelles informations exportées et dans quel ordre.
Ainsi l'export sera personnalisable, et je pense par la même occasion que vos scripts n'aurons pas besoins d'être mis à jour.

Nuri wrote:

Et quand on spécifie du matos, on précise, au minimum, le nom du FABRICANT, la référence, le numéro de commande et une petite description textuelle histoire de capter rapidement de quoi il s'agit.
Quand j'ai fini mes plans, j'envoie la nomenclature à mon client qui se débrouille tout seul avec ses FOURNISSEURS.
En fait, je connais quasiment jamais le nom des fournisseurs de mes clients, ca sort déjà du cadre de mon travail.

Tu dit au minimum : Fabricant, référence, numéro de commande et petite description.
Ensuite tu dit "le client se débrouille avec sont fournisseur".
Mais le numéro de commande, c'est bien un numéro propre au fournisseur. Du coup tu devrais juste avoir à renseigner Fabricant, référence, et petite description.
Je me trompe ?
J'avoue n'avoir pas trop réfléchie au truc, je suis comme Laurent, quand je refais un schéma éléc, je renseigne uniquement le nom du fabricant, la référence "fabricant" du produit et un petit texte d’explication.

C'est le comble, je suis le développeur, mais j'utilise pas souvent QET dans mon boulot, et encore moins de manière aussi poussé que vous nomicons/laughing

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

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. nomicons/wink

637

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

641

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