Nouveautés de la version de développement 0.7 (Page 9 of 23)

Revision: 5166
Author:   scorpio810
Date:     2017-12-10 17:10:19 +0100 (Sun, 10 Dec 2017)
Log Message:
-----------
Add a Qfontdialog for choose policy for independent text item, not
finished yet !

Bon, même si ce n'est fini (reste a créer une page ou une action dans la config plutôt que de lancer le widget directement quand on clique sur configurer QET) j'ai pensé que ça pourrait intéresser certains.

Pour l'instant les textes barrés et soulignés ne sont pas pris en compte.

La configuration des polices est aussi sauvegardée dans le fichier config QET (ou dans la base de registre pour ceux sous Windows) et est appliquée au lancement de QET.

En attendant vos retours.

Enjoy ! 

@ scorpio810 :
Ah, cela n'agit que sur diagramitemfont .
Je croyais que tu voulais faire und QFontDialog pour diagramfont.
Pour avoir pas mal joué dans le qelectrotech.conf, je sais qu'il faut pas trop tripoter diagramfont sinon cela crée des décalages en fonction de la métrique de police utilisée.

Perso j'ai pas besoin de changer a police des champs de texte. Mais y'a sûrement quelqu'un à qui ce sera utile.
Pourquoi ne pas avoir mis le QFontDialog dans le dialog des "Propriétés des champs de textes" ? (quand on fait clic droit sur un champ de texte)
C'est parce que diagramitemfont est globale ?

@ Joshua :
je vais tester.

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.

oui, effectivement y'a pas de méthode pour ǵérer ce comportement.
C'est peut-être pas plus mal d'ailleurs, car je viens d'y repenser :
étant donné que le QAbstractItemView possède lui-même une SrollArea, si on le fait défiler et que la QSpinBox choppe le focus au passage, tu changes la valeur de celle-ci sans t'en rendre compte .
Je connais ce comportement dans FreeCAD qui utilise un QAbstractWidget pour éditer les paramètres de ses objets 3D et parfois, en scrollant, tu changes des valeurs dans les QSpinBox. Faut toujours faire attention, c'est parfois pénible.

Oui, pas besoin de "Tagg". Normalement, la valeur de "Source du texte" et de "Information" doivent suffire à définir l'information contenu dans "Texte".
2 infos (paramètres) pour définir un texte, c'est déjà pas mal !

Bizarre... : ce matin, la boîte de dialogue s'ouvre au premier plan (devant la fênetre QET). J'y comprends rien !
En tout cas, le dialogue doit être modal par rapport à l'appli, ca c'est sûr.

this->setWindowModality(Qt::ApplicationModal);
    #ifdef Q_OS_MAC
    setWindowFlags(Qt::Sheet);
    #endif

(je sais bien que tu sais écrire ce code, c'est juste que je commence à confonter mes connaissances Qt à la réalité... )

Et pour finir... j'ai le droit de faire mon chieur ?!?
Dans le QAbstractItemView des textes dynamiques, est-ce bien nécessaire de faire un sous-niveau d'arborescence pour "Source du texte" ?
Je pense que le QAbstractItemView serait plus simple à manipuler et plus facile à comprendre du premier coup d'oeil si on avait tous les paramètres d'un texte dispo en un seul niveau d'arborescence.
Quand on a plusieurs textes ouverts, les yeux s'y perdent un peu dans toutes ces lignes...
Comme ca ?

Chouette

J'ai survolé le commit :
pour changer le comportement des QSpinBox, il fallait donc bricoler les QEvent qui y sont associés et pas chercher dans les paramètres de QAbstractItemView.
J'ai vu que t'as fait pareil aussi pour les QComboBox, c'est bien !
Ca n'avait pas l'air simple à régler, bravo .

Concernant le QColorDialog pour changer la couleur des textes, j'ai remarqué ceci :
- je démarre fraîchement QET
- sur le folio, j'insère un élément contenant un texte dynamique rouge avec source "texte utilisateur"
- je clique sur ce texte et clique sur le champ "couleur"
- le QColorDialog s'ouvre au premier plan
- je change rien et clique sur "annuler"
- le texte rouge devient noir --> anormal

Dès qu'on annule le QColorDialog, les textes redeviennent noir.
De plus, si on annule le QColorDialog, et qu'on re-clique sur le QPushButton pour changer la couleur, plus rien ne se passe (le dialogue ne s'ouvre pas).

Chez moi, le QColorDialog s'ouvre au premier plan seulement à la première ouverture. Les fois d'après, il s'ouvre toujours derrière le fenêtre principale de QET. Si je redémarre QET, même comportement : la première fois devant, et après toujours derrière.
J'ai regardé la doc de QColorDialog et il est explicitement écrit que :
"The static functions provide modal color dialogs."
Donc je pige pas pourquoi ce machin s'ouvre derrière la fenêtre QET, sauf au premier appel.

Une petite piste pour chercher l'erreur :
si je clique sur le QPushButton qui appelle le QColorDialog, le dialogue s'ouvre.
Je touche à rien d'autre et je ferme QET. Le QColorDialog existe toujours et n'a pas été détruit par QETapp.
Visiblement, il y a un problème de parenté avec ce dialogue.

@ Laurent :
oui j'avais les mêmes warnings.
Mais je pense pas qu'ils soient en rapport avec le QColorDialog qui existe aussi en dehors de l'application.

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)

@ Joshua :
merci pour le infos et les liens, ca me permettra de comprendre quelques notions suplémentaires au passage.

Ben justement, c'est ca le hic, il devrait t'en afficher qu'une seule si le QColorDialog était vraiment modal par rapport à l'appli.
Maintenant, essaies le truc suivant :
- démarre QET et crée un projet vierge
- dépose un élément, crée un texte dynamique quelconque.
- enregistre
- clique sur le champ "Couleur" pour ouvrir le QColorDialog
- touche à rien (laisse le dialogue ouvert) et ferme QET
Alors ? Est-ce que le dialogue existe encore ou pas ?

EDIT :
autant pour moi... je constate 2 comportements différents avec le QColorDialog selon l'environnement de bureau utilisé.
Sous KDE, tout à l'air de se comporter normalement :
- quand le dialogue est ouvert, je ne peux pas fermer QET
- donc on a l'impression que le dialogue est modal (je pense plutôt que c'est KWin qui gère ca tout seul)

Sous Unity, je peux fermer QET et le dialogue reste ouvert, comme si c'était une appli à part entière.
Et le launcher de Unity me montre clairement 2 icones. Quand je clique le QColorDialog pour la couleur des conducteurs, le Launcher Unity me montre qu'une seule icône.

Sous KDE, la barre des tâches montre toujours 2 icônes. Que ce soit le QColorDialog des textes dynamiques out celui des conducteurs ne change rien.

Je pense que le Gnome Shell de Joshua doit se comporter à peu près comme Unity.
?

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.

La moulinette existe déjà en fait, et vous l'utilisez depuis que les textes non taggé sont convertie en texte dynamique, les "ancien" textes taggé sont exactement les mêmes que les non taggé (en fait ils ont un tagg qui est à "none").
Le problème ne venais pas du tagg lui même (ce n'est qu'une propriété texte) mais de la gestion que l'on faisait par la suite de ces types de texte (coller une Xref dessous, ou alors le commentaire dans un encadré, tenir à jours quand ils sont basé sur une formule etc....).
Maintenant tout ce que je pouvais préparer en temps masqué est fait, la prochaine étape c'est la bascule.

Pour les exceptions en fonction de la version avec laquelle le projet a été créé initialement, je ne peut rien garantir, mais les textes d'éléments sont très vieux, et, ont peu changer depuis leurs créations, donc ça devrais allez.

Pour les imports de configuration de textes, je comptais pas utiliser le QSetting, qui n'est pas fait pour ça en plus.
Je pensais créer un dossier "element_text_pattern" dans le dossier de conf de qet avec dedans des fichiers xml, un par configuration, qui du coup est compatible avec ta demande.

Je n'avais pas pensé à la possibilité de les intégrer au projet, mais oui y'a pas de soucis.

Mise à jour du compilateur clang et du framework Qt sur les prochains bundles macOs :

QElectroTech V 0.70-dev r5191
Compilation : CLANG 9.0.0 (clang-900.0.39.2) - built with Qt 5.10.0 - run with Qt 5.10.0 using 16 thread(s)