Search options (Page 5 of 26)

car c'est une info à part entière, au même titre que "localisation".

oui mais cela ne concerne que le folio.
En premier lieu, l'info "groupe fonctionnel" du folio est destiné à ordonner le folio dans une arborescence mais cette focntion n'existe pas (pas encore ?) car le panel "projets" n'a pas (pas encore ?) été revu pour afficher une arborescence, par exemple :

=GF1
      +LO1
            1
            2
            3
            101
            102
      +LO2
            1
            2
=GF2
      +LO1
            11
            12
            13

Pour l'instant, on peut entrer les valeurs =GF1, =GF2, +LO1 et +LO2 dans les infos cartouches, mais le panel n'affiche que les "labels" de folio, c'est-à-dire cela :

1
2
3
101
102
1
2
11
12
13

Si, par exemple, sur le folio =GF2+LO1/11, je dois câbler dans un circuit un relais qui appartient à =GF1, il faut clairement que je puisse entrer cette info dans l'identification du relais. Et donc, il me faut un champ "groupe fonctionnel" dans les propriétés de l'élément.
Et, en plus, si ce même relais n'est pas dans +LO1 mais dans +LO2 alors là aussi il faut que je rentre cette info dans ses propriétés. Mais dans le cas de la "localisation", c'est déjà faisable, vu que le champ correspondant existe déjà dans le widget.

Pas moyen d'utiliser ca dans les formules. Il faut que l'info sorte dans sa propre colonne dans l'export csv.

@ Laurent

merci pour ta réactivité .

Par contre, je pense que je t'ai un peu emmêlé les pinceaux :

Le "groupe fonctionnel" ne manquait que dans le widget "propriétés de la sélection". A part ca, ce champ avait déjà été implémenté dans les cartouches. C'est le champ qu'on avait nommé "installation".
Pour les formules de labels, c'est la variable %M. Pourquoi elle a été nommée "Machine", j'en sais rien !
Bref, on a quelques problèmes de terminologie.

Faut faire attention avec les traductions.
En allemand, l'identifiant [=] s'exprime par "Anlage".
Ca se traduit littéralement en francais par "installation" mais je pense pas que ce soit le bon terme car la signification est trop vaste en francais. "Groupe fonctionnel" traduit mieux ce qui est réllement signifié en allemand.
Partout où on a "installation" dans la GUI, il faut le changer en "groupe fonctionnel".

Si je récapitule :

identifiant =
[DE] Anlage
[FR] Groupe fonctionnel
[EN] Plant

identifiant +
[DE] Ort
[FR] Localisation
[EN] Location

La variable devrait s'appeler %{plant}. On la traduira par :
[FR] Groupe fonctionnel
[DE] Anlage
[EN] Plant
"Nom du groupe fonctionnel du projet", ca veut rien dire. On peut avoir 50 groupes fonctionnels différents dans un seul projet. Cette info n'est pas liée directement au projet.

C'est une demande du client qui dispose de schémas uniquement en pdf (générés par Eplan) et qui souhaite les modifier à sa sauce tout en se passant d'Eplan. Bref, il veut une nouvelle base sous QET pour pouvoir travailler les schémas.
Les schémas sont réalisés selon l'IEC 81346 (avec groupe fonctionnel = et localisation +) est c'est pas facile-facile de tout reprendre sans casser les labels existants.
Mais pour l'instant ca va, j'ai pas eu de gros obstacle insurmontable.
A part peut-être le fait qu'il manque toujours le champ "groupe fonctionnel" dans le widget propriétés de l'élément. Je contourne le problème en utilisant "champ auxiliaire 1" mais ce serait mieux d'avoir un champ dédié à cela (exactement comme quand t'as implémenté le champ "localisation").

Pour rappel, dans un schéma selon IEC 81346, les composants sont totalement identifiés avec les 3 variables :
[= groupe fonctionnel] + [+ localisation] + [- repère].
Le relais =G1+A1-K1 n'est pas le même que =G2+A1-K1 bien que tous les deux aient le même "label" -K1.
Joshua a écrit:

Et y'a pas du tout moyen d'enregistrer la config QET dans un fichier sous Windows ?
J'ai vu qu'on peut aussi utiliser QSettings pour enregistrer dans un format custom, par exemple un fichier xml :
http://doc.qt.io/qt-5/qsettings.html#registerFormat
J'ai bien conscience que ca demande du boulot, c'est clair.
Mais comme j'écrivais dans mon post précédent, cette fonctionalité fait partie des "fonctions pro" : il faut pouvoir changer rapidement toute la config pour jongler entre différentes exigences, en l'occurence pour différents clients.

Petite proposition d'amélioration :

lorsqu'on ajoute un nouveau texte dynamique à un élément, ce serait bien si la largeur du texte était fixée à -1 par défaut.
C'est, je pense, la configuration qui fonctionne le mieux pour la plupart des cas (textes sur une ligne dans 95% des cas).

Pour l'instant, le défaut est à 0 et cela provoque un comportement qui n'est pas facile à comprendre au premier abord (faut faire joujou quelques minutes avant de capter les différences).
Le réglage à -1 est aussi celui qui fonctionne le mieux avec l'option d'alignement.
Le comportement de l'option d'alignement est assez dépendante du réglage de largeur. Pour les débutants, c'est assez déroutant et, si on n'expérimente pas assez, on a même l'impression que le comportement d'alignement est bogué.

Ouuulllllaaaaaa...    J'allais l'oublier celle-là :

Alors ca, ce serait vraiment le pied !
Plus besoin de convertisseur. Attention, je respecte le boulot énorme de Ronny mais le convertisseur a ses limites, notamment avec les arcs de cercles et les polylignes, les blocs, etc... Rien d'insurmontable mais il faut parfois être très bricoleur pour arriver à ses fins .
Cela permettrait aussi d'importer plus facilement tout graphique vectoriel embarqué dans un pdf (par exemple, des morceaux de schémas Eplan ), de travailler avec la puissance d'Inkscape et d'importer directement dans QET.

@clabacchio

If you add the dynamic text from the diagram editor it won't work!
Because this is the purpose why "dynamic texts" have been implemented: to give you the possibility to add some text on a particular instance of an element. That's the reason why they had been named DYNAMIC texts.

If you want that your changes are made in all instances of the element, do this:

But I'm not sure it will work...
It works very good with STATIC texts.

@seyt

die Bauteile unter QET Sammlung / Elektrik / Allpolig / Verbindungen sind sehr alt und entsprechen nicht mehr so richtig dem aktuellen Stand von QElectroTech.
Sie sind teilweise unvollständig und bestehen zum Teil nur aus Anschlüsse (die roten Balken mit dem blauen Ende).
Also in die Benutzersammlung kopieren und mit Linien vervollständigen. Dann passt es auch mit dem Ausdruck und man muss nicht die Option "Anschlüsse zeichnen" anwählen.

Zu "richtungsweisenden Verdrahtung" sagt man auch "Zielverdrahtung" und es sind die Bauteile, die man unter QET Sammlung / Elektrik / Allpolig / Verbindungen findet:
- Combine
- Splice
- Thru left
- Thru right

@ Calypso

du nutzest ja das Wort "Element" (wie im Französischen) und nicht "Bauteil".
Gibt es einen Grund dafür?
Soll ich Software-umgreifend das Wort "Bauteil" durch "Element" ersetzen?
Welches Wort macht im Deutschen am Besten Sinn?

désolé, me suis mal exprimé.
Si j'ai bien compris, on peut aussi empaqueter le langage avec le programme, ce qui aurait quelques avantages :
- l'utilisateur n'a plus rien à installer, simplement faire tourner l'éxécutable
- on évite les problèmes de compatibilité de version de Python
L'inconvénient, c'est la taille de l'appli qui devient assez conséquente.

Il y a quelques semaines de cela, je m'étais intéressé à Python pour voir si je pouvais porter ma macro LibreOffice vers ce langage. J'en aurais aussi profité pour rendre la macro (le script Python, en l'occurence) plus universelle et donc utilisable pour tout le monde (d'avantage configurable et moins portée sur mes propres besoins). Mais en fait, faut tout ré-écrire...

J'avais donc créé un fichier *.ui avec QtDesigner pour faire la petite GUI du programme.
Ensuite je l'ai convertie en Python en utilisant PyQt5.
C'est super pratique : on peut très rapidement créer une GUI sans faire une ligne de code C++. Et ensuite, toutes (mais j'en suis pas sûr) les classes Qt et tous les widget Qt peuvent être utilisés par le script Python. Donc facile de faire un FilePicker pour choisir le fichier csv.
Je précise que je n'ai pas porté la macro LibreOffice vers Python. J'ai simplement créé une GUI pour faire quelques essais.

Après, j'ai essayé d'empaqueter le tout avec PyInstaller. Cela a fonctionné : j'avais donc un petit éxécutable Python avec toutes ses bibliothèques. Puis après, ca a commencé à devenir plus difficile car j'ai remarqué que l'appli ne tournait que sur ma machine, donc j'ai dû manquer quelque chose pendant l'empaquetage (visiblement, le langage Python n'était pas empaqueté dans l'éxécutable).

Puis, finalement, j'ai laché l'affaire car, même en portant vers Python, le script resterait assez lourdingue pour l'utilisateur vu qu'il faut toujours passer par la collection utilisateur pour lui fournir les éléments nomenclature. Et il faut lui demander où elle se trouve, où est le fichier csv, etc.
Bref... Pour moi, c'était trop peu de gains pour beaucoup de travail.

Si un jour l'édtition de nomenclature était intégrée à QET, y'aurait moyen de faire ca en 2 clics de souris (sous-réserve d'utiliser un fichier config).

Je pense que tout le monde est d'accord avec cela.
Mais, au final, les problèmes sont toujours les mêmes et d'ordre pratique :
le manque de bras et de temps. Donc il faut des roues de secours. Souvent, ce sont des scripts ou des outils externes.
Faut rester réaliste, c'est déjà exceptionnel le travail réalisé par Joshua et Laurent à eux seuls.

Pour en revenir au générateur de Raul :
ce sera déjà plus facile à mettre en oeuvre si le script Python était empaqueté avec toutes ses bibliothèques pour en faire une vraie application à part entière (avec PyQt5 ou un truc dans le genre).
Mais bon... avec ca, on aura un script qui pèsera plus que QET lui-même, mais c'est pas trop grave par les temps qui courent (quand on voit ce que pèsent certaines applis Windows...).

De toute facon, la gestion des bornes et des câbles, c'est le plus difficile à venir à mon avis.
Surtout les câbles !
Quand je vois parfois le temps que je passe à configurer des câbles sous Eplan, j'ai l'impression d'aller plus vite en faisant tout à la main dans QET.
Donc, des automatismes, je veux bien, mais il faut que cela se répercute en gain de temps pour l'utilisateur sinon quel est l'intérêt de s'embêter avec des usines à gaz ?...

Quand Joshua en sera aux câbles, j'essaierais de lui faire part de quelques réflexions.
Mais j'avais déjà dis que tant que les connexions (bornes rouges et bleues) n'auront pas leurs propres textes, ce sera difficile de générer des borniers et câbles en automatique.

Ben moi j'ai l'impression d'avoir déjà exprímé la plupart des grosses demandes durant les 3 dernières années :
- les bornes et câbles
- l'édition nomenclature
- les entrées/sorties API
- la gestion des données d'articles
- la norme IEC 81346
Voilà pour les plus gros morceaux.

Pas toujours facile de trouver le compromis entre "faire le gros lourd" et "faire avancer le logiciel"

Juste une petite proposition au passage :

Quand on charge un element_text_pattern peut-être faudrait-il simplement ajouter une petite checkbox "écraser les textes existants". Si la checkbox n'est pas coché, on ajoute le element_text_pattern aux textes déjà existants (fonctionnement actuel).

C'est bien ce qu'il me semblait :

If install Debian
then stable
else "tu vas ramer comme un malade"

Je confirme, Timeshift c'est vraiment bien quand on a système toujours au bord du gouffre.
Timeshift est maintenant livré d'office avec Mint car ils ont laissé tomber leur politique étrange de mise à jour.