Bon, je prends 5 min pour dire merci concernant l'amélioration de la conso RAM. C'est vraiment une différence phénoménale !

Sur mon Ubuntu 15.10, juste après le démarrage de QET, le moniteur système m'affiche une conso de 37,5MB alors "qu'autrefois", c'était plutôt 900MB voire 1GB. nomicons/blink

Lorsque j'ouvre mon dernier projet avec 137 folios chargé à bloc avec 16 folios nomenclature (sans UUID) et de gros elmt avec des milliers de primitives issus du convertisseur dxf, la conso monte à 1,1GB.

A la fermeture du projet, la conso reste à 1,1GB. Sur Windows 10, en revanche, une partie de la mémoire est vidée, mais ca on connaît, c'est la différence de gestion mémoire entre Windows et Linux.

A la réouverture du même projet, la conso reste calée à 1,1GB alors "qu'autrefois" elle montait déjà à la réouverture du projet (sans fermer QET entre temps).

Par contre, j'ai pas encore fait le test "longue durée" de plusieurs heures de travail car je suis occupé avec un autre projet en ce moment. Mais dès que j'en aurais l'occasion, je surveillerai le comportement de la RAM.

Je confirme le problème.
Je confirme également que "nettoyer le projet" fonctionnait parfaitement dans les anciennes versions de QET.

Ce défaut est apparu graduellement avec les implémentations du nouveau panel d'éléments.
Il doit y avoir un petit oubli quelque part.

Hello,

here are some good news since the last posted message.

Hilário joined the team and is in charge of the translation in brasilian portuguese. The GUI is almost completely translated and activated in the software.

Davi joined also the team, but as software developer. He will add (and has already added) some new functionalities to titleblocks, component numbering, etc.

In the project properties, tab cross references, the new variable %F was added to differentiate %{folio-id} from %folio.

The variable %f corresponds to the variable "%{folio-id}" available in the titleblock: it's the numerical position of the folio in the project. Its value is dynamicaly updated when the order of folios is changed.
The new variable %F corresponds to the variable "%folio" available in the titleblock. %F stores a constant that is not updated when the order of folios is changed.

Thus, it is possible for the user to number folios the way he wants:
with numbers and non continuous numbering, with letters (*/=-+) or a mix of both, or something else!

A new tool allows to create several new folios in one action. This tool takes the user parameters (folio properties) and numbering rules into account by creating the new folios.

Here is a video example:

https://download.qelectrotech.org/qet/f … lio_3.webm


From now on, the user can configure the text format of the cross references as he wants.
It is valid also for the auto numbering functionality of conductors.

https://download.qelectrotech.org/qet/forum_img/XREF_format1.png

The texts of cross references can now be longer as before without overlapping symbols.

https://download.qelectrotech.org/qet/forum_img/XREF_format4.png

In the element properties widget, the variables %f %F %l %c can be used in the field information.

The csv export to the nomenclature (parts list) takes these variables into account.


The long and hard work made by Joshua to build a new element panel is now finished and is very valuable.

This new panel manages the element collections and the old one manages the project view and the titleblock collections.

All the panels can be arranged by the user the way he wants: one over the others as tabs, one above and one below as split view, or detached from the main window when a HDPI or several displays are used.

As a result of the new panel, the RAM consumption of QET decreases from more than 1GB to about 30MB at program startup.

Yes, you read it right!!! nomicons/w00t

Here on MS Windows:

https://download.qelectrotech.org/qet/forum_img/RAM.png

The reason is simple: at program startup, the element pixmaps are not generated anymore. They are only created when the collection tree is explored.
Even if the whole collection tree is opened, the RAM consumption does not exceed 300MB.

The startup time of QET is also reduced by this improvement. Only about 7 sec. on Laurent's computer:

laurent@debian:~$ time qelectrotech

real 0m8.926s
user 0m6.920s
sys 0m0.136s

* Once the editing of an element is finished, it is automaticaly updated in the panel and is ready to be dragged & dropped onto the folio.
* Copying folders of elements is also made instantly so that they are updated on the fly.
In the most cases, there is no need to reload the collections anymore.

A memory leak was found and solved thank the competence of Mehdi.


Enjoy! nomicons/smile

429

(38 replies, posted in News)

@Galexis

non, ce sera un dock séparé, ce que je trouve très bien :-)
Vu le nombre de fonctionalités qui pourront être implémentées pour chacun des docks, il vaut mieux séparer.
Ca évitera le basar --> les actions réalisables dans le dock "projets" n'auront pas grand chose à voir avec celles du dock "collections".
D'autant plus que lorsqu'on travaille avec 2 écrans ou même un seul en FullHD ou UltraHD, il y a assez de place pour afficher correctement tous les docks ainsi que l'espace de dessin.

430

(38 replies, posted in News)

galexis wrote:

En revanche, je ne suis pas sûr qu'il soit utile de pouvoir régler par type le format d'affichage : si on utilise le label folio pour les bobines, on l'utilisera aussi pour les protections et les commutateurs.

Je rejoins Galexis sur cette histoire. Je vois pas l'intérêt de séparer les formats pour les références croisées. J'ai jamais eu de cas où cela aurait pu être utile "dans la vraie vie". Je gratte, je gratte... mais je vois pas.
Mais bon, comme Laurent, je pense qu'il vaut mieux ne pas y toucher pour l'instant, surtout si ca permet de faire les entrées/sorties d'API.

galexis wrote:

En même  temps, ces nouveautés ne font pas beaucoup réagir

Attends, ca va venir... rien qu'en faisant la traduc en allemand j'ai eu plein de petites propositions d'améliorations qui me sont passées par la tête. Mais en ce moment, pas trop le temps pour QET car j'ai plein de boulot pour un client qui n'utilise pas QET.

431

(38 replies, posted in News)

scorpio810 wrote:

Ajout de folios non conséquents par leur numérotation, possibilité de numérotation avec des lettres et des caractères */=- +, etc

C'est bon ca ! nomicons/wub c'est Galexis qui va aussi être content !
Par la suite, il faudra voir comment ce système s'intègrera dans le panel (arborescence) du projet.
Pour l'instant, je pense pas encore qu'on puisse faire des documentations =/+ avec le nouveau widget de numérotation.
L'idéal serait que les conteneurs = et + aient leur propres variables dans les cartouches.
En plus, ce sera plus facile pour créer le QTreeView du panel projet.
Bon... j'avoue que j'ai pas encore compris toutes les subtilités du nouvel outil de numérotation nomicons/whistling

scorpio810 wrote:

Le déplacement dans un projet au clavier est maintenant géré par les touches PgUp, PgDn

Cool ! Comme dans un certain logiciel commercial que j'utilise trop souvent...

scorpio810 wrote:

Et comme toujours : Joshua continu de progresser sur le code du nouveau panel d’éléments.

* Une fois l’édition d'un élément fini il est rafraîchi instantanément dans le panel, prêt à poser sur le folio.
* Les copies de dossier dans les collections sont pareillement instantanées, les éléments sont prêts à être posés sur les folios.

Fini le rechargement des collections avec ce nouveau panel.

Alors là, merci, ca m'enlève vraiment une grosse épine du pied. En conception, quand on crée beaucoup d'éléments, le rechargement des collections était parfois assez pénible car ca cassait constamment "le workflow" avec QET.


@Laurent
ce serait pas une bonne idée de faire toutes les news en anglais et francais à partir de maintenant ?
Je pense que les nouveaux développeurs brésiliens et argentins apprécieront, ainsi que tous les users non francophones.
Je veux bien faire les traductions en anglais mais faut pas s'attendre à une extrême réactivité de ma part (disons 1 à 3 jours pour la traduction, selon la taille de la news et mon temps libre).

Hi Calypso,

I've reached good results by using QCAD.
Open your dxf file with QCAD. Explode all blocks. Convert splines, arcs and curves to polylines. Then the DXFto ELMT converter can work. But be carefull, converting splines, arcs and curves to polylines makes the dxf file much bigger. It should not become bigger than 1 or 2MB otherwise the converter will obviously crash.

Another workaround for big dxf files:
1. Print your dxf file as a pdf file in A4 format with QCAD. Before printing the pdf, scale your drawing so that it becomes really small on the A4 sheet (don't exceed about 2x2cm)
2. Open the pdf file and print it as a svg file (on GNU/Linux, this can achieved with Evince)
3. Open the svg file with Inkscape and save it as a dxf R14 file (while saving, the option LWPOLYLINE must be disabled in the "save as..." dialog)
4. Convert the dxf file to elmt with the converter

You will have some aliasing problems because of the many convertions but it doesn't really matter if your dxf file is really high detailed.

This way, I manage to reduce a 6MB dxf file (very high detailed) to less than 600KB.

Voilà, j'ai terminé le tuto :

Tutoriel QETTUTO001V02

Le lien pour télécharger la macro est dans le tuto.

Salut friskolon,

je viens de finir un projet avec plus de 130 folios.
Avant de commencer les schémas, j'ai créé un cartouche personalisé et je l'ai configuré comme cartouche standard pour ce projet, comme tu l'as également fait :
Menu "Projet" / "Propriétés du projet" / registre "Nouveau folio" / onglet "folio" / Informations des cartouches --> Modèle.
Après, il faut aussi rentrer tes variables cartouche à cet endroit dans l'onglet "personnalisées" (en bas à droite de "principale").
Pour moi, cela a très bien fonctionné, j'ai pas eu un seul souci pendant tout le déroulement du projet.

Après, pour ton cas n°2, je peux pas trop te répondre. Vraisemblablement, il manque un petit truc dans le code pour prendre totalement en compte le nouveau cartouche.

plop Laurent, merci pour le lien !
Je sais déjà que certains arrivent à faire marcher cette carte son. Mais après, faut passer à la pratique et c'est là que la perte de cheveux s'accelère...
La dernière fois que j'avais essayé, c'était il y a 2 ans avec la distri KXStudio qui donnait des résultat pas mal mais tout n'était pas fonctionnel. Faudrait que je réessaie à l'occasion.
Bon allez, j'arrête là avec mon hors-sujet caractérisé nomicons/blush

J'ai lu le fil sur linuxfr.org. J'ai l'impression de mieux comprendre nomicons/smile

En fait, la technologie snap est à double-tranchant. C'est bien et c'est pas bien...

Si j'ai bien compris, tant qu'un logiciel est libre (sources, empaquetage, distribution...) il vaut mieux rester sur du paquetage deb car le paquet est plus compact. Et surtout, apt-get garanti la cohérence et la sécurité du système et des librairies, justement en utilisant les dépendances.
C'est un des grands avantages à utiliser des distribs GNU/Linux en deb ou rpm et c'est pour ca qu'on les aime.

Toutefois, l'empaquetage snappy peut faciliter le travail des développeurs de logiciels propriétaires et je pense que c'est la véritable finalité de snapcraft. De cette manière, ils pourront faire comme sous Windows : fournir un binaire éxécutable avec toutes ses dépendances et donc fonctionnel "out of the box". Ainsi, le support et la maintenance de l'application sont clairement plus faciles qu'avec un système deb, ce qui ouvre la porte au business sur Linux.
Snappy va favoriser les applications propriétaires car les développeurs n'auront plus d'excuses du genre :
"on peut pas développer pour Linux car il y a trop de versions différentes. C'est un travail qui ne sera jamais rentable."
"la maintenance est impossible car les systèmes Linux sont trop hétérogènes"
"on peut pas vous proposer de support car votre problème vient de cette librairie que nous n'avons pas créée"
etc...

Revers de la médaille avec snappy : le système finira par devenir vulnérable et l'anti-virus sera obligatoire, et là, ca me plaît déjà beaucoup moins nomicons/pinch

Par contre, pour certaines applications "pro" ou "semi-pro", snappy offrira de gros avantages, notamment pour réaliser des pilotes (drivers) pour du matériel spécifique, ce qui, jusqu'à aujourd'hui, est LE GROS TALONT D'ACHILLE de GNU/Linux.

Perso, je suis bassiste amateur et j'essaie depuis 2008 de faire de la MAO sous Linux. Mission impossible nomicons/angry
J'ai une carte son RME multicanaux (http://www.rme-audio.de/en/products/fireface_800.php) qui tourne sur une interface Firewire.
Tiens d'ailleurs le forum de la société RME m'en rappelle un autre nomicons/whistling :
 https://www.forum.rme-audio.de/
Bref, pas moyen d'en faire quelque chose sous Linux. Y'a bien le projet FFADO (http://www.ffado.org/) mais c'est pas encore au point... et vraisemblablement, ca ne le sera jamais...
Je fini donc toujours les nerfs à vif et puis vient la phase de déprime : installer Windows sur une machine dédiée à la MAO.
Donc pour ce genre de trucs, snappy, pourquoi pas ?...

Ok Laurent, merci pour ton avis un peu plus averti que le mien sur l'empaquetage snap. nomicons/shocked
J'avais pas vu les choses sous cet angle - transformer Ubuntu en Windows - et effectivement, je suis déjà moins festif...
On peut donc considérer que les paquets snap seront mal accueillis par les distribs deb et rpm. Ce qui me pousse à penser que Canonical a besoin de cette technologie pour lancer son Phone (pour faire tourner plus d'app sur Ubuntu Phone ?) et pas pour le Desktop.

Après, c'est clair que fournir 800MB de libraries Qt pour faire tourner QET.. c'est pas pensable... nomicons/dizzy

Donc je comprends mieux ton intérêts pour le dépôt Lauchpad.net. Merci du travail effectué !

Quelques news pour faire patienter encore un peu :

Hier soir, j'ai retravailler la macro LibreOffice qui crée les éléments nomenclature. J'ai corrigé une grosse erreur dans le code et ajouté quelques sécurités pour éviter qu'elle ne plante trop facilement.

J'ai également ajouté une procédure qui remplace les caractères :

<  >  &  '  "

par leur codage en xml, soit respectivement :

&lt;  &gt;  &amp;  &apos;  &quot;

Ce qui signifie que l'utilisateur peut utiliser ces caractères dans le nom des éléments sans que cela pose de problème par la suite.

Surtout, j'ai fini de la rendre éxécutable sous Windows. Donc ca y'est, ca marche aussi sous Windows.

Reste plus qu'à documenter le tout dans le tuto et à poster ici.

scorpio810 wrote:

J'attends des retours de votre pars pour ce nouveau dépôt PPA, merci d'avance.

Je passerai à la nouvelle PPA à la fin du printemps, début de l'été, soit quand j'aurai upgradé mon système vers la nouvelle LTS 16.04. En attendant, je reste sur l'ancien pinning.

scorpio810 wrote:

Oui, tu pourras rester sur les versions LTS, sauf si t'as un écran HDPI.. à moins de faire des paquets Snaps !

Sinon, je trouve l'idée des paquets snaps vraiment super, aussi bien pour les développeurs que pour les utilisateurs. Fini les sources externes, les dépendances insolubles, les systèmes flingués...nomicons/laughing
Reste à voir si c'est techniquement bien réalisé et comment tous les dérivés d'Ubuntu ainsi que les distributions en rpm vont accepter la chose.
Les paquets snaps, c'est aussi peut-être, à terme, le début d'Ubuntu en rolling release.
La cerise sur le gateau étant des paquets snaps qui se déploiraient aussi bien sur GNU/Linux, MS Windows que Mac OS X... Mais là je m'égare...nomicons/rolleyes

Toutefois, cette innovation me pose une question de fond. A partir du moment où un debianeux fait :

$ apt-get install snapcraft

Est-ce qu'on peut alors dire que Debian est basé sur Ubuntu, qui est basé sur Debian, qui est basé sur Ubuntu...?

Classe nomicons/cool

Est-ce que cela veut dire que je pourrais rester sur la prochaine LTS (16.04) jusqu'à la sortie de la prochaine (18.04 ?) pour toujours pouvoir éxécuter la dernière version de devel QET ?

Avant d'utiliser QET, je n'installais que des LTS sur ma machine. Mais depuis que je suis le devel de QET, je suis plus ou moins contraint d'installer les versions intermédiaires d'Ubuntu (à cause des versions de Qt).

scorpio810 wrote:

Tu dois pouvoir modifier les arguments de ton lanceur, du moins si c'est toujours possible avec Win 10?

oui, cela fonctionne. Faire comme ceci :
démarrer QET avec le raccourci sur le Bureau.

Dans la barre des tâches, faire un clic droit sur l'icone QET et choisir "accrocher l'application" (j'ai Win10 en allemand donc je connais pas la version francaise de cette entrée du menu).

Fermer QET.

Dans la barre des tâches, faire un clic droit sur l'icone QET, placer la souris sur "qelectrotech", faire un clic droit et choisir "propriétés".

Une fenêtre s'ouvre. Aller à l'onglet "raccourci".

Dans le champ "cible", pointer vers le batch. Chez moi, cela donne :
"C:\Program Files\QElectroTech\Lancer QET.bat"

Dans le champ "éxécuter dans", entrer le repertoire d'éxécution. Chez moi :
"C:\Program Files\QElectroTech"

Eventuellement, changer l'icone en pointant sur l'icone QET. Chez moi :
%ProgramFiles%\QElectroTech\ico\qelectrotech.ico

Fermer la fenêtre d'édition des propriétés du raccourci, et hop, ca devrait marcher.

oui Laurent, c'est exactement ca, c'est un "raccourci à la noix" qui pointe sur le exe et pas sur le batch (j'avais oublié cette histoire sous Windows). Fait chi** nomicons/angry
Ca fait plus de deux semaines que je me demande pourquoi QET marche pas sur mon Win10...

J'aurai bien aimé avoir un vrai lanceur qui marche dans la barre des tâches mais bon, tant pis, je démarre QET depuis le raccourci bureau (comme dans les années XP avec le bureau bardé de raccourcis nomicons/grin )
Y'a pas moyen de régler ce petit problème un jour ? Ca donne pas une bonne impression de QET, au premier contact...
Ou pas une bonne impression de Windows, mais ca, c'est une autre histoire...

Installer le build 0.51svn4442 en tant qu'administrateur ne résoud pas le problème.

Par contre, il semblerait que le problème vienne d'une intégration incomplète dans Windows car je viens de rendre compte des faits suivants :

QET fonctionne correctement quand je le démarre depuis le raccourci sur le bureau.

QET ne fonctionne pas correctement quand je le démarre depuis la barre des tâches, en bas de l'écran.
De plus, dans la barre des tâches, Windows n'utilise pas l'icone QET, mais une icone générique.
Voir le screenshot :

Je viens d'essayer avec le build 0.51svn4442, même problème.

En fait, tant que je suis dans la session qui a installé QET, tout fonctionne correctement.
Par contre, dès que je redémarre Win10 (et donc une nouvelle session est crée), QET ne marche plus correctement : il repasse en francais et ne trouve plus les collections.

Bonjour :-)

je suis en train d'essayer de faire tourner ma macro LibreOffice sous Windows, en l'occurence Win10 en machine virtuelle.
Il y a quelques temps déjà, j'ai téléchargé le build v0.51 svn4400 et je l'ai installé avec l'assistant.
Tout s'est bien passé.
Je lance QET, ca dure un petit peu, le temps que les collections soient chargées pour la première fois. Puis je vais dans le menu config de QET pour changer la langue. Je ferme QET puis je le redémarre.

Et là, oh surprise, l'application démarre à vitesse grand V, et pour cause, les collections ne sont pas chargées du tout. La langue de la GUI n'a pas changé non plus.

Je suis allé voir dans C:\Users\[username]\Application Data\qet
et effectivement je retrouve la structure habituelle de la collection perso (avec \elements, \titleblocks...).
Certes vide, mais c'est normal, je n'y ai encore rien enregistré.

La collection officielle n'est également pas chargée. Bref, mon brave QET se comporte comme s'il ne retrouvait pas ses petits.

Ensuite, j'ai désinstallé QET j'ai réinstallé le même build et je retrouve le même comportement :
au tout premier démarrage, tout se passe bien et ensuite, à tous les démarrages suivants, QET ne charge pas les collections et ne prend pas compte des modifs effectuées dans qelectrotech.conf (la langue, par exemple).

Est-ce un oubli dans le build ou est-ce que cela vient de mon Win10 ?
Est-ce un problème connu et est-ce qu'il y a un remède ?

Salut f.franck

j'ai pas encore complètement fini le tuto. Il manque encore la partie vraiment intéressante avec l'export csv et le réimport avec macro LibreOffice.
Toutefois, je pensais que ce serait utile de poster l'état actuel du tuto avant que tu ne perdes définitivement patience nomicons/whistling

Voici donc le lien :

tuto (incomplet)

EDIT : LIEN DÉSACTIVÉ, VOIR PLUS BAS POUR LA VERSION FINALE

Même incomplet, ca permet déjà de se faire une idée.

447

(7 replies, posted in Elements)

Pour la lampe, va voir dans cette catégorie :

Collection QET
    Electrique
        Multifilaire
            Signalétique et commande
                Signalements optiques

Sinon, dans le moteur de recherche au dessus des collections, tu peux aussi taper "lampe" et voir tous les résultats correspondants à ce mot clé.

Salut Fuken,

aux dires de Joshua, les fonctions "enregistrer" et "enregistrer sous" vont bientôt être rétablies dans l'éditeur d'éléments. Ce n'est pas un bug, juste des fonctions désactivées pour raison de modification du code sous-jacent.

En attendant, tu peux essayer ce workaround :
fais un glisser/déposer de l'élément qui t'intéresse de la collection QET vers la collection utilisateur. Dans ce cas de figure, il est alors possible d'enregistrer un élément que l'on a modifié.
Cela fonctionne avec l'ancien (''Panel d'éléments'') et avec le nouveau (''Collection d'éléments'') widget.

Je remonte un bug pour le moins gravissime :
depuis aujourd'hui il m'est impossible d'enregistrer un élément dans ma collection perso.
Lundi dernier, tout marchait encore correctement.

Dans l'éditeur d'éléments, quand je clique sur le bouton "enregistrer", je me prends le message d'erreur :
"Impossible d'enregistrer l'élément"

Oui, mon élément dispose d'un champs de texte défini en tant que label.

J'ai essayé plusieurs variantes :
- copier un élément existant et l'enregistrer sous un autre nom
- en créer un complètement nouveau avec l'assistant
Rien ne marche. J'ai vérifié les droits en lecture/écriture du répertoire /home/nuri/.qet et tout est bon. Bref, je comprends pas ce qui bloque.

Est-ce que d'autres utilisateurs peuvent confirmer ?
je roule avec QET 0.51 svn4420

@ f.franck

encore un peu de patience. Il faisait beau ce week-end alors je n'ai pas passé énormément de temps devant mon écran.
J'ai déjà bien entammé le toturiel. Il sera fini dans les jours qui viennent.
Ca réclame pas mal de boulot, et c'est du travail bénévole, alors un peu de patience :-)