Search options (Page 7 of 26)

pis aussi, les vidéos 4K, ca fait ramer à mort le serveur TuxFamily qui a déjà bien du mal avec les FullHD habituelles.

@ Unalcalde:
yes, show a table to change the order of the terminals is a great idea
It is much more convenient for the user how can "take care" of the terminals strips when the drawing of the schematics is done and not every time a new terminal is created.

@ Joshua :
yes, adding special info fields for terminals is nice
I'm also thinking about the information "terminal number" which needs an extra field.
For example :
Label = -X1
Terminal number = 1

Hi Bob, look in this folder in your PC (I guess you are on Windows):

C:\Program Files\QElectroTech\examples

The example files are pretty old now. I don't know if it really suits to what you're searching for.

Bonjour Michel

l'équipe QElectroTech devrait bientôt mettre un nouveau site web en ligne.
La page "download" intégrera alors les instructions complètes pour installer depuis la ppa.

Dès le départ, je pensais que ce serait mieux de virer la fenêtre double-clic pour éviter les fonctions doublon. Mais bon... c'est pas moi qui bosse sur le code alors si c'est pas beaucoup de travail de maintenance...

Sinon, ce serait bien d'étudier l'insertion du retour chariot dans tous les textes. J'ai l'impression qu'il manque pas grand chose pour que ca puisse fonctionner facilement.
Je m'en sers déjà d'une manière détournée :
j'ouvre un éditeur de texte et j'écris un truc du genre :

a
b

je sélectionne le texte de a à b (comme ca, le retour à la ligne, invisible, est copié également), je copie et j'insère par exemple dans le champ "commentaire" d'un élément.
Dans "commentaire", j'écris avant "a" par exemple "ventilateur condensateur" puis, après "b", j'écris par exemple "n°1".
Ensuite j'efface "a" et "b" et mon texte est correctement formaté :
[center]ventilateur condensateur
n°1[/center]

Sous Eplan, le retour chariot est disponible avec le raccourci ctrl+Entrée.

Dans QET, on pourrait utiliser le même raccorci et en plus ajouter une entrée "insérer un retour chariot" dans le menu contextuel.

Et comme les textes dans les champs du widget de l'élément s'écrivent tous en une ligne (sans formatage) on pourrait utiliser la représentation habituelle du retour chariot :

Hallo Walter,

es gibt keine Rastereinstellung in QET.
Der Raster ist fest und dem Abstand zwischen zwei Punkten entspricht 10 Pixel, sowohl im Schaltplan- als auch im Bauteileditor.
Wenn du im Bauteileditor mit Strg+Maus nicht klar kommst, hast du noch die Möglichkeit, die Koordinaten deiner grafischen Formen direkt zu editieren (im rechten Panel).
Die Koordinatenangaben beziehen sich auf dem "Hotspot" (der rote Kreuz).
Es ist etwas lästig, Formen so zu editieren, aber es ist halt dann perfekt exakt.

Für komplexere Symbole würde ich dir eher empfehlen, den DXF Konverter zu benutzen, sonst wirst du wahnsinnig im Bauteileditor .

Ich nutze selber QCAD (quelloffen und gratis, Windows und Linux), um dxf Dateien zu kreieren.

Die Lernkurve ist ziemlich steil am Anfang aber dann kannst du alles zeichnen/importieren in QET.

Ok, je pense piger.

Ok, donc en principe tu sais faire (quand je fais une demande ou une proposition, c'est pas toujours facile de cerner le niveau qu'il faut en C++ pour arriver à ses fins, donc parfois je propose des trucs faciles et parfois... quasi infaisables ).
Et super, tu vas stocker dans du xml, je pense que c'est un bon choix.
Par contre, je pense pas qu'il faille mettre le dossier "element_text-pattern" dans le .conf de l'OS car, du point de vue de l'OS, ce dossier n'a finalement pas de rapport avec la config du logiciel (à fortiori si ces configs sont aussi intégrées dans les projets).
Je voyais ca plutôt dans :
/home/nuri/.qet/user-settings
à côté de /elements et de /titleblocks.
Pourquoi faire comme ca ?
Parce qu'il y aura certainement à l'avenir d'autres petites configurations à stocker quelque part et ce dossier devrait préparer la route pour de nouveaux développements.
Par exemple, avec l'ajout d'une nomenclature dans le projet :
l'utilisateur configure l'apparence des formulaires, etc. et évidemment, il aimerait bien enregistrer cette config pour pouvoir la réutiliser ou pour l'envoyer à un tiers.
Pareil avec l'édition du sommaire, si on décide de le rendre configurable.

Ce serait bien d'avoir aussi l'avis de Laurent, vu qu'il fait quasiment tout le packaging pour quasiment tous les OS, il doit avoir une idée de ce qui est pratique à déployer sur différents OS et de ce qu'il l'est moins.

Ok...
Donc on aura un fichier xml qui stocke une configuration d'affichage pour les textes dynamiques.
Est-ce qu'il faut donner une extension particulière à ce fichier xml ? (comme pour le fichier xml du projet, renommé .qet alors que c'est un banal xml).
Par exemple :
pour les configs de textes dynamiques, on donne l'extension .qetdt (dt = dynamic texts)
pour les configs de nomenclature, on donne l'extension .qetpl (pl = parts list)
pour les configs de sommaire, on donne l'extension .qettc (tc = table of contents)
etc... en fonction des développements qui se feront...
et on place tous ces fichiers dans /home/[user]/.qet/user-settings.
Ensuite, les file pickers pourront filtrer les fichiers en fonction de leur extension.

Est-ce bonne idée ?
Est-ce lourdingue à coder ?

@ noir_desir :
c'est un développement qui a été réalisé l'année dernière (flèches direction pour se déplacer dans le folio).
Je suis moi aussi franchement pas un fan de cette "amélioration" qui provoque des bugs qui n'existait pas avant.
Par exemple :
quand je sélectionne un report de folio, je ne peux plus le bouger ni vers le haut, ni vers la gauche avec les flèches directionnelles. Par contre vers le bas et vers la droite oui...
J'ai pas encore compris pourquoi cela marche avec certains élémens mais pas avec d'autres.

Un petit revert de commit ne serait pas totalement inapproprié
Je pense que cette modif est restée dans le code plus pour des "raisons politiques" (ne pas blesser les nouveaux développeurs) que par pragmatisme.

Sous KDE, le QColorDialog s'ouvre toujours en avant-plan (devant la fenêtre QET) mais l'OS considère que c'est une appli à part entière car, dans la barre des tâches, il m'affiche 2 fenêtres pour QET (l'appli principale et le dialogue).
Alors que si j'ouvre le QColorDialog pour choisir la couleur des conducteurs, par exemple, le dialogue est considéré comme une sous-fenêtre de l'appli et l'OS ne montre qu'une seule fenêtre dans la barre des tâches.

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.

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 ?

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