501

(36 replies, posted in News)

galexis wrote:

Au final mon avis est qu'il faudrait mettre en place les borniers auto avant les câbles.

Moi je pense que ca marche ensemble, sinon comment représenter automatiquement les câbles dans les plans de borniers si la fonctionalité n'existe pas ?!?
Joshua a certainement raison, d'abord les câbles, ensuite les borniers.

galexis wrote:

Peut-être même qu'il faudrait avant tout ça, rendre Qet compatible avec le découpage des schémas selon la norme IEC en installation, localisation (=, +, - ) ?

Ca, c'est la question qui tue...
Quelque part, je suis de ton avis, car l'implémentation des =/+/- aura des répercussions dans beaucoup de fonctionalités de QET. Donc autant tout chambouler maintenant avant d'ajouter de nouvelles fonctionalités qu'il faudra aussi chambouler par la suite.
L'inconvénient, c'est que ca va beaucoup ralentir le developpement de QET.
Mais personnellement, et d'un point de vue purement égoiste, j'ai aujourd'hui d'autres paramètres qui pondèrent fortement cet avis. Pour l'instant, je travaille avec QET uniquement pour un seul client. Pour faire les schémas électriques de ses machines, je n'ai pas vraiment besoin d'un système =/+/-. Avec les variables de cartouche et le champ "localisation" des éléments, on peut déjà mettre en place un pseudo-système facon IEC 81246. Bon, c'est vraiment pseudo mais ca va, j'me débrouille...
Pour moi, la priorité c'est clairement les câbles et les borniers. Tout simplement parce que cela me fera gagner beaucoup de temps. Alors que les =/+/-, ca prépare le terrain pour l'internationalisation, les gros projets et l'industrie pure et dure.

Joshua wrote:

Je peut vous faire un petit patch ou l'on ne garde pas en mémoire chaque primitives, pour voir si ça va mieux.

A toi de voir où tu poses tes priorités : soit la sortie de la 0.5 finale, soit le patch. C'est peut-être un peu aventureux de faire un tel patch juste avant la sortie de la 0.5. A mon avis, on aura pas assez de recul pour voir si le patch ne crée pas de nouveaux problèmes.

Joshua wrote:

Dans ton cas nuri, je suppose que tes tableaux sont remplis de texte et de rectangles ou lignes, chaque primitive étant gardé en mémoire, ça grimpe vite.

ouais ok, mais là on parle d'environ 100MB pour un elmt. Quelque part, l'ordre de grandeur n'est pas juste. A la rigueur, 5 ou 10MB je veux bien, mais pas 100. Ca semble beaucoup trop.
Compare avec une video MP4 en HD 1080p d'une minute, ca fait combien de MB ?!?

Scorpio810 wrote:

Apres un reboot de Qet : switcher d'un langage à l'autre ne consomme pas plus de RAM.

Oui, de toute facon, pour avoir toute la GUI dans une nouvelle langue, il faut redémarrer QET, ce qui vide la RAM. Donc le problème ne vient pas de la gestion des langues.

Pour résumé le topo :
ce qu'on savait déjà, c'est que QET ne gère pas de facon optimale la conso RAM lors de la création des pixmaps et de la recharge des collections.
Ce qui est peut-être nouveau, c'est une haute (voire très haute) conso RAM lors de l'insertion de elmt de type nomenclature contenant beaucoup de primitives.

ben, ok Laurent, mais ce que je ne comprends pas, c'est pourquoi un elmt qui pèse 90KB fait augmenter la conso RAM d'un facteur 1000 (quasiment) une fois qu'il est dans le projet .qet nomicons/blink

pach30310 wrote:

Je remonte juste un bug car il est n'est pas normal d'avoir à reprendre un élément fini .

C'est vrai, oui.

Concernant le problème de RAM, je viens de constater un truc :
J'ai fini la traduc en anglais de mon projet, j'exporte la nomenclature en csv, je fais tourner ma macro LibreOffice qui me crée 7 nouveaux elmt contenant les tableaux de nomenclature.
Je retourne sous QET, recharge les collections et la conso RAM augmente d'environ 100MB (ca on le savait déjà).
Puis, je crée les nouveaux folios pour tirer/déposer les elmt de nomenclature. Et là, à chaque elmt insérer, c'est environ 50 à 100MB de conso RAM en plus. Bizarre, car les elmt de nomenclature pèsent même pas 90KB.
Pour essayer, je tente alors l'expérience suivante :
j'efface tous les elmt nomenclature de mon projet, je nettoie le projet et j'enregistre. La conso RAM baisse légèrement (max. 50 à 100MB en moins). Puis je réinsère mes elmt nomenclature et c'est à nouveau 50 à 100MB de conso RAM en plus à chaque tableau insérer (qui s'ajoute à la conso RAM précédente). Et ainsi, en esseyant plusieurs fois, comme hier, j'ai vite atteint 10 voire 12GB de conso RAM

Conclusion provisoire :
la gourmandise de RAM n'est pas provoquée exclusivement par "recharger les collections", il y a un truc encore plus glouton là derrière...

Edit :
heu... j'avais oublié que cela provient vraisemblablement de la création des pixmaps des elmt nomenclature (vu que ce sont des éléments avec une surface énorme).

bonjour,

j'ai moi aussi déjà constaté ce petit problème :
certains textes ne gardent pas la position qui a été définie dans l'éditeur d'éléments une fois qu'ils se trouvent placés sur un schéma. Mais cela ne concerne jamais tous les textes, en général, juste un ou deux qui ne veulent pas rester à leur place.
Bon, en l'occurence, ton symbole est bien construit et chez moi, les textes s'affichent à la bonne place.

Il faut réouvrir ton elmt avec l'éditeur d'élément et remettre les textes rebelles en place. Enregistrer l'élément, fermer l'éditeur et recharger les collections. Jusqu'à présent, cela a toujours marché.

Et concernant le problème des en-têtes (avec QET svn4266), voici donc le problème illustré en vidéo :

vidéo

scorpio810 wrote:

Pense à faire des pauses, sauvegarder et fermer Qet, prendre l'air, ou en griller une !

J'en grille déjà assez comme ca !

scorpio810 wrote:

Je sais bien que dessiner avec Qet est prenant, mais 7 heures d'affilées c'est pas un peux trop?

ben quoi, c'est mon boulot :-)
Quand j'ai fait les plans au printemps, c'était parfois 10 ou 11 heures par jours...

scorpio810 wrote:

Par contre j'y pense, tu es toujours avec la lib libqt5core5a en 5.5.1 de Debian Sid installé à la sauvage sur ton Ubuntu 15.10 en Qt 5.4 ?

Nan nan ! Sur tes conseils, j'ai tout dégagé au plus vite avant que mon cher Ubuntu ne se transforme en Win98...
Bon, comme d'hab, ca m'a couté quelques gouttes de sueurs (Qt Linguist qui marche plus, le VLC player qui fout le camp, Qt Creator qui veut pas ouvrir les .pro, Compiz qui fait des galipettes...) puis finalement tout rentre dans l'ordre. Comme quoi, Linux c'est quand même bien pensé : même avec un neuneu aux commandes, le système retombe toujours sur ses pattes.
Mon install date de la 14.04. Depuis, j'ai fait 3 dist-upgrade et le système tient toujours le coup. Ils sont forts, c'est presque de la rolling release maintenant...

scorpio810 wrote:

J'ai déja passé plus de 5 heures consécutives en dessin de schéma, et pas remarqué cette explosion de ram utilisée, surtout limité par les 2GIo de ram sur le vieux pc au taff, le swap aurait ralenti la machine..et le kernel aurai killer le process Qet.

Avec 16GB de RAM, je me suis dit que j'avais pas besoin de swap...nomicons/whistling

Georges Brassens wrote:

"Quand on est con.... on est con..."

scorpio810 wrote:

Je conçois que Qet est pas encore parfait avec la gestion de la RAM sur le cachedb, mais la c'est carrément une grosse fuite mémoire ... ou de mitrailler la touche F5.

J'ai rajouté des données aux éléments de la collec embarquée, fait la traduction en anglais, switché entre allemand/anglais, reloadé les collections un bon paquet de fois (mais c'était pas encore du mitraillage)...
Cependant, y'a quand même quelque chose de louche. La conso RAM montait vraiment vite.
Tant pis si ca peut pas être réglé pour la 0.5 mais ca doit pas être que du bonheur sur les petites machines.

Je remonte encore quelques trucs avant la sortie de la 0.5 finale.

1.
Aujourd'hui, j'ai bossé 7 heures d'affilée avec QElectroTech et j'ai remarqué une inquiétante consommation de RAM.
Au démarrage, QET prend environ 950MB de RAM selon le moniteur de GNOME.
J'ouvre mon projet de machine CNC (comptant 44 folios et une seule image embarquée), la conso RAM passe alors à 1,4GB. Jusque là tout va bien, même si c'est déjà beaucoup mais ca reste dans les normes de ce genre de soft.
Et puis graduellement, au cours de mon travail, la conso RAM n'a cessé d'augmenter. Jusqu'à atteindre 10,3GB !!!
J'ai alors fermé puis redemarré QET et les choses redeviennent normales. Jusqu'à ce que la conso RAM recommence à augmenter dans des proportions alarmantes.
Visiblement, il y a un truc dans le code qui ne vide pas la RAM. Je pense peut-être au bouton "recharger les collections" dont je me suis beaucoup servi aujourd'hui.

2.
Un petit problème de rafraichissement :
Dans les propriétes du folio, les cases à cocher "afficher les en-têtes" ne fonctionnent plus à la volée. Il faut qu'il se passe quelque chose dans la vue de l'éditeur de schéma pour que les en-têtes prennent en compte la nouvelle valeur des cases à cocher.

hello rdsivd,

I don't know XLpro3. I only use QElectroTech and Eplan.
I've took a look on the Legrand XL3pro website. This program is only for windows. I'm on Ubuntu 15.10.

this program insert the symbole of a circuitbreaker and the offers the user the posiblity to choose the refrence of the needed circuitbreaker
It also calculated the size of the cabinet and offers a tarif price for the  project

Nice feature! I think we need something like that in QElectroTech but maybe without pricing and cabinet sizing functionalities.

For your information, I use QElectroTech to engineer industrial machines and facilities, not for electrical building installation. The core of my job is automation with PLC's (automotive, pharma, CNC-machines...).
At the moment, I've made only one project with QElectroTech in a real professional environment. And all other projects with Eplan...

let me now in a email of you need it to have some data for testing

Thank you for your offer but I'm unfortunately a real poor programmer, so I don't know how to test a database and how to link it to QElectroTech. I've tried to understand the Qt/C++ programming environment of QET but I got some hawful headaches...

I have some ideas how the management of article data could be implemented in QET but I can not write the Qt/C++ code. I can describe the behaviour of QET from a user point of view. Maybe the next days if I find some time...

Salut Laurent et merci pour les corrections !
Concernant 2 : c'est bon aussi, le fond ne repasse plus automatiquement en blanc quand je clique sur imprimer (je parlais de la vue dans l'éditeur de schéma, pas de la vue d'apercu avant impression).

Salut Morvion,

avant de pouvoir implémenter correctement ces fonctionalités dans QET, il faudrait poser sur papier une réflexion solide décrivant exactement le comportement attendu du logiciel. Sinon, ca part dans tous les sens et cela ne rend pas facile le travail des développeurs.
De la même manière, il faudrait également réaliser une sorte de "cahier des charges" à proposer aux développeurs concernant la gestion semi-automatique des borniers et des câbles pour pouvoir espérer un jour réaliser des plans de borniers et des listes de câbles en quelques clics de souris.
Il me faudrait environ une semaine de libre pour pouvoir tout mettre au propre sur papier. Pour l'instant, toujours pas trouvé le temps...

Tant qu'on en est à faire du polissage de logiciel, j'en profite pour remonter 3 babioles (quoique la première est parfois bien génante) :

1.
Quand je crée une basic shape sur le schéma, par exemple une ligne droite, je clique pour placer le premier point et là, le zoom ne se comporte pas normalement : au lieu de zoomer vers le curseur de souris, le zoom s'effectue vers le coin supérieur gauche du folio. Ce comportement bizarre disparait dès que la basic shape est complètement créée (quand on a placé le deuxième point de la ligne).

2.
Si je travaille avec le fond du folio en gris et que je clique sur l'icone "imprimer", le fond passe automatiquement en blanc.

3.
Le sommaire automatique utilise la police du système et non la police de qelectrotech.conf.

Je te laisse tester Qet dessus, pas le temps ni l'envie de faire joujou avec ce Win 10 en ce moment.

ok !

Pour Win10, il faut absolument une version 5.x de Virtualbox.
Y'a même le support USB3 maintenant, mais j'ai pas testé si ca marchait correctement.

En VM Win 10 était inutilisable, trop lent, donc je l'ai dégagé...

Bizarre... moi j'ai plutôt l'impression inverse : Win10 me semble plus rapide que Win7 dans VirtualBox.
Par contre je n'ai que essayé Win10 32Bit.
Et même avec ton proco AMD "de la mort qui tue" c'est lent au point d'être inutilisable ?
Avec mon i7-4750HQ, Win10 tourne vraiment bien en machine virtuelle.

Oui, un bon moyen pour te faire passer du coté du magnifique Inkscape (dessin vectoriel)

héhé... c'est pas l'envie qui manque... c'est plutôt le temps.
Surtout que y'a des bons tutos Inkscape sur OpenClassRoom. Je compte bien m'y mettre mais me demande pas quand.

Dans le code de QET, et en admettant que la collection d'icônes svg soit complète, y'a moyen d'utiliser que du vectoriel pour la GUI ou il faudra toujours passer par des png de différentes tailles (32x32, 64x64...) ?

ok Laurent, merci du tuyau.
Malgré ce qui est indiqué sur la page http://qelectrotech.org/download.html, dans le paragraphe "Development version", qui indique unstable, je vais donc changer la ppa de QET en :

http://debian.qelectrotech.org/qet/debian/ stable main

et virer le depot Debian Sid ainsi que libqt5core5a en version 5.5.1 pour retourner en 5.4.

Par contre ça m’étonne que la dernière Ubuntu soit livrée avec la version 5.4 de Qt?

Et pourtant c'est le cas.

Les variables créées dans les cartouches n'accèdent pas à des données externes à QET (comme par exemple le nom du fichier).
Cela signifie qu'il ne suffit pas d'appeler une variable "filename" pour qu'elle écrive le nom du fichier. Cette fonction n'est pas (pas encore ?) implémentée dans QET.

Tu peux cependant écrire dans les variables de ton projet une nouvelle ligne :
%filename avec la valeur "C:\bla bla bla...\mon_super_projet_qelectrotech.qet".
Mais cela reste une variable statique : si tu changes l'emplacement de ton fichier, la valeur de la variable n'est pas actualisée.

Voici une solution. Je sais pas si c'est une bonne solution mais j'ai réussi à installer QET dev sans flinguer mon système nomicons/wink

Ajouter cette ppa au système :

deb http://ftp.de.debian.org/debian sid main
sudo apt-get update
sudo apt-get install libqt5core5a
sudo apt-get install qelectrotech qelectrotech-data qelectrotech-examples

merci !

J'ai ajouté le fichier et apt-get veut maintenant installer la version de développement depuis la ppa.

Mais l'installation ne s'effectue pas car il y un problème de dépendance avec les paquet Qt5.
QET dev a besoin de libqt5core5a (>= 5.5.0) et apt-get a seulement le droit d'installer 5.4.2+dfsg-2ubuntu9.
Désolé de t'embêter encore avec ces histoires de dépendances mais là je suis vraiment pas un as.
Et ce coup-ci, j'ai pas envie de sabrer mon système à moitié avec des expériences de newbie du terminal...

Hier soir, j'ai fait passer mon Ubuntu 15.04 vers la 15.10.
Contrairement aux

sudo apt-get dist-upgrade

réalisés dans le passé (dans les années 2008-2011), tout c'est bien passé et le système semble sain.
Par contre, QElectroTech est descendu en version 0.4 (installé depuis les repos officiels je suppose).

J'ai donc fait :

sudo apt-get remove qelectrotech qelectrotech-data qelectrotech-examples

J'ai vérifié que la ppa de QElectroTech est bien active :

http://debian.qelectrotech.org/qet/debian/ unstable main

puis le passage obligatoire :

sudo apt-get update

J'ai relancé :

sudo apt-get install qelectrotech qelectrotech-data qelectrotech-examples

puis :

qelectrotech --version

qui me redonne :

0.4

snif... nomicons/sad

Comment faire pour réinstaller la version de développement depuis la ppa ?

Salut Joshua,

Est-ce qu'il y a une possibilité pour que QET puisse recadrer correctement les schémas lors de la réouverture du projet, par exemple ?
Ce problème de marges est également apparu dans mon projet de machine CNC.

le problème disparaît si on fait - + colonne ou - + ligne

Cela peut éventuellement donner une piste vers la solution du problème.

Il y a quelques mois de cela, j'ai essayé un écran à résolution 4K avec ma distro Ubuntu.
J'ai vite laissé tomber et je suis retourné en 1920x1080px car Linux n'est pas encore mûre pour les hautes résolutions. Même avec la mise à l'échelle (scaling) de la GUI, tout ne marchait pas correctement. Certains programmes passent bien et d'autres, c'est la catastrophe.
J'ai aussi essayé d'utiliser QET avec l'écran 4K. C'est vraiment à la limite de l'utilisable. Les icônes et les menus sont ridiculement petits, quasiment illisibles.
Le gros challenge derrière l'arrivée des moniteurs 4K (et maintenant 8K !...), en plus d'avoir un scaling de la GUI, c'est la refonte de toutes les icônes qui devront être faites avec des images vectorielles (svg) et non plus matricielles (png).
Parce qu'un png de 32x32px affiché en gros sur un écran 4K, c'est vraiment pas beau du tout...

Avant il faudra s’en équiper, vos dons sont toujours les bienvenues et servent pour les machines.

La 0.5 finale arrive et mon petit don aussi :-)

"fixé" c'est du franglais ;-)