Search options (Page 25 of 33)

Bonjour,
les nouveaux textes sont maintenant proche de la fin (je parle uniquement de l'éditeur de schéma) et comme je l'avais dis auparavant, le but est d'en finir avec les anciens textes d'éléments.
Actuellement, seul les textes comportant des tags sont encore utilisés en tant "qu'anciens textes", mais plus pour longtemps...
Grace aux groupes de textes et aux textes encadrés, nous pouvons enfin remplacer le binôme : texte taggé "label" avec dessous texte encadré "commentaire", par le nouveau type de texte, avec le même rendu visuel (pour ceux qui n'auraient pas capté comment, un texte info -> label, dessous un texte info -> commentaire + encadré, le tout dans un groupe de textes avec alignement centré et pour ressembler au maximum aux anciens textes, un ajustement vertical qui va bien).

Concrètement, pour les projets existants, le bascule sera automatique (pensez quand même à faire une sauvegarde de votre .qet avant, on ne sait jamais).
Pour les nouveaux en revanche les choses vont changer.
-Dans l'onglet "informations", il n'y aura plus de case à cocher en face de "label", "commentaire" et "localisation", car dorénavant, ce n'est plus justifié.
-Dans l'éditeur d'éléments, plus d'obligation de rajouter un texte avec le tag "label", étant donné que cela peut-être fait depuis l'éditeur de schémas.
-Avec les éléments fraîchement posés sur un folio, pour obtenir "l'ancien style : label + commentaire encadré", il faudra (au pire des cas avec un élément sans texte) ajouter deux textes et les paramétrer en conséquent.

Le problème, c'est que cela sera très très lourd à l'usage (à mon avis) de devoir répéter encore et toujours la même action. J'ai donc pensé à cela :
Poser un élément lambda, créer les textes comme dit plus haut, puis cliquer sur un bouton, "exporter la configuration des textes".
Ensuite, il suffira de cliquer sur un bouton "importer une configuration de textes" et tada tout est déjà fait.
Il sera possible de créer autant de configurations que besoin et d'en importer plusieurs dans un même élément étant donné que ce sera pour résumer, une automatisation de créations de textes.
Les termes "import/export" ne sont peut-être pas les plus adaptés, mais c'est du détail.

Voila, à vous maintenant.

Pas exactement, il fallait "attraper au vol" les QEvent destiné aux QSpinBox et QComboBox, afin de crée un comportement personnalisé, le tout ni dans le QAbstractItemView ou dans le widget (spinbox ou combobox) mais le dans le QStyledItemDelegate. Il s'agit du design pattern MVC revisité à à la sauce Qt.
Bon je te dit ça uniquement pour information, embrouille toi pas trop la tête avec ça pour le moment, ça commence à être des notions avancé de la POO (et Qt en utilise beaucoup d'autres, le système de signaux/slot étant une sorte de Observer et aussi énormément de Flyweight).

Pour le QcolorDialog, je vais regardé si je trouve quelque chose.

Laurent:
Pour les warnings, c'est pas grave, je fais des switchs sur des enums, et tout les valeurs de l'enum n'est pas testé dans le switch. (plus de 160 pour QEvent::Type)

Ok je pense pouvoir régler ça.

Je suis sûre à 99% que ce n'est pas possible surtout quand je regarde la doc ici

Ça oui, c'est déjà le cas avec "source du texte"

Pour le champ tagg, je l'avais mis afin que l'utilisateur puisse écrire un truc perso mais qui ne serais pas utilisé par QET, pour une potentiel utilisation future.
Mais t'est pas le premier à poser la question, et au vue de l'évolution des textes (je ne pensais pas aller aussi loin avec les nouveaux textes) et des utilisateurs "avancé" comme toi qui n'en trouve aucune utilité, je pense que je vais l'enlever.

Je vais regarder ça, mais je promet rien car chez moi, le dialogue s'affiche bien au premier plan, donc ça va pas être simple de savoir si oui ou non le problème est réglé.

Et pour finir oui les choses ne sont en cour dans l'éditeur d'élément.

Wahou, vous êtes motivé les gars  

Je comprend pas trop l'histoire des deux éléments ?
De plus tu dit : "depuis l'éditeur d'élément, de définir le type d'info que doit contenir un champ de texte." je voie pas trop en quoi les nouveaux textes pourront t'être utile, dans ce cas précis?
Après effectivement, j'aurais bien vue la création sommaire/nomenclature un peu comme ce qui existe déjà avec la création de borniers (natif dans qet bien sure).
Allez je vous laisse réfléchir à tout ça.
@Nuri
tu avais déjà tenter d'apprendre c++ et Qt, mais tu avais trouver ça pas facile. Tu attaque un truc pas simple avec le sommaire/nomenclature

EDIT : Corrigé commit 5140 + exemple maj

C'est bon j'ai identifié le problème.
En fait on travail sur un  très vieux fichier dans lequel les conducteurs d'un même potentiel n'ont pas tous les mêmes propriétés, ce qui n'est pas possible depuis longtemps, et le code est fait en conséquent.

Pour Laurent :
Techniquement on demande le premier item d'une QList qui est vide = crash.
Par contre j'ai fait une découverte étrange le problème est aussi présent dans la trunk.
Sur Qtcreator si je compil en debug, j'ai toujours le crash en revanche si je compil en release le crash n'est pas systématique, pourtant au vue de comment est fait le code ça devrais toujours crashé.

Je n'ai pas encore fait la correction pour l'instant. Par contre dans le commit je vais aussi modifier le schéma de manière à ce que les conducteurs d'un même potentiel partage les même propriétés.

Oui et non  
Oui c'est normal, car la fonctionnalité n'existe pas.
Non c'est pas normal car effectivement ce serais bien que la numérotation soit de gauche à droite.

tant que c'est constructif, y'a pas de mal
Par contre je te suis pas trop, la partie que tu trouve pas génial, c'est la classe customElement, ou alors les différentes classe graphicspart (arc, rect, ellipse etc....).
A savoir que les deux agissent sur deux partis très différente de QET, et ne peuvent pas être unifié, car leurs but est très différents.

Oui ça m'intéresse beaucoup, surtout si tu propose de virer du code dupliqué

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.

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

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 ?

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.

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