QElectroTech version 0.5 Release Candidate 1 released (Page 2 of 3)

Rien à voir: j'ai remarqué que lorsqu'on ouvre un projet existant et qu'on ajoute un folio, on ne peut pas enregistrer le projet, le bouton est grisé.
De même avec le déplacement de folio.

Normal, la gestion des folios n'est pas encore ajouté à la pile historique : donc ajouter un folio vide, déplacer des folios et rien d'autre, le programme ne voit aucun changement donc l'icone idoine reste grisée.
Par contre tu peut enregistrer sous : et écraser l'ancien.

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

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

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

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

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.

video

Pour la conso ram (qui est un vrai problème) je suis entrain de me pencher dessus.
Alors déjà il est claire que ce sera pas pour la 0.5.
Ensuite, je lie beaucoup de doc Qt pour résoudre le problème, je pense avoir trouvé la solution (et si c'est le cas, ce sera une solution pérenne) mais il y aura beaucoup de boulot.
Donc une grande partie du développement de la 0.6 se portera dessus. Il est possible (conditionnelle: j'ai peut être tort) que suite à ce changement le démarrage de qet soit plus rapide qu'actuellement.

Pas de problème chez moi, sur LM17.2.

Je viens d'essayer avec tes éléments nomenclature sur un projet vide :

RAM utilisée au départ ~850Mio.
Je pose tes 7 éléments
RAM utilisée à la fin ~ 1,5Gio

Edit : plus l’élément est complexe, plus la ram utilisée sera élevée, après tu peux le poser indéfiniment ça ne montera presque pas.

Une fois le projet ré ouvert la Ram utilisée retombe à 1.1Gio.

Au sujet de la ram qui grimpe abusivement j'ai peut être une idée.
Lorsque habishek à crée l'export en dxf, il à fait un truc que je trouve pas top.
Quand on crée un pixmap d'élément en fait on "dessine dessus".
Pour dessiner on utilise des forme simple (ligne, ellipse, rectangle tec....), abishek garde ces formes en mémoire pour chaque élément afin de s'en servir lors de l'export en dxf et je pense que cela consomme pas mal de ram, et c'est proportionnel au projet. Ce qui aurais été bien pour l’export c'est plutôt de lire la description dans le xml puis le convertir en dxf, ainsi y'a pas de conso ram supplémentaire, en gros c'est dxf-to-qet dans l'autre sens.
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.
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.

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 ?!?

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.

Il n'y a pas que ça, sqlite pourrais aussi en être la cause :
http://www.qtcentre.org/threads/31287-Sqlite-Memory-Use

Faut que je fasse des tests pour connecter un PostgreSQL, ou un autre SQL sur le cache pixmap pour voir.

un elmt c'est juste une définition en XML d'un format qui se rapproche du SVG, après il y a toute la conversion avec le painter dans la scène graphique avec des traitements graphique qu'on lui demande d’exécuter en plus ou moins suivant le rendu souhaité, le tout stocké en RAM:
Quelques exemples :
p -> setRenderHint(QPainter::Antialiasing, false);
p -> setRenderHint(QPainter::TextAntialiasing, true);
p -> setRenderHint(QPainter::SmoothPixmapTransform, false);

QPainter p(&preview);
p.setRenderHint(QPainter::Antialiasing, true);
p.setRenderHint(QPainter::SmoothPixmapTransform, true);
// Translation de l'origine du repere de la pixmap
p.translate(hotspot_coord);
// L'element se dessine sur la pixmap
paint(&p, 0);

pen.setWidthF(0.4);
pen.setCosmetic(true);
pen.setColor(Qt::darkGray);

// utilisation d'un trait "cosmetique" en-dessous d'un certain zoom
if (options && options -> levelOfDetail < 1.0) {
final_conductor_pen.setCosmetic(true);

Dans le même style : un fichier DWG de 77Kio, si tu le convertis en DXF il pèse maintenant plus de 3.5Mio..

Merci Nuri de ton retour, déjà tu nous fais plaisir qu'en tu dis que tu as travaillé dessus 7 heures d'affilées, le code est maintenant bien plus solide qu'il a quelques mois en arrière.

Ce qui est normal, après les phases d'ajouts de nouvelles fonctions, il faut stabiliser tout ça, tout logiciel en passe par là.

J'arrive quand même à avoir un comportement bizarre et un crash, sans perte de données, heureusement pendant la sauvegarde avec tes symboles : câble brin haut/bas si je les supprimes : elles restent en partie affichées.

Juste remarqué ce problème dernièrement sur mes folios borniers, pas eut le temps d'investigué la dessus !

Les petites machines n'explosent pas hein, uhuhu, seulement travailler avec sur de gros projets faut être très patient.

Ça doit être le cas aussi avec ton Eplan, un Catia, Autocad, Solidworks sur une machine en Celeron avec 1Gio de RAM, tu dois pas travailler confortablement... c'est pas pour rien qu'ils vendent des workstations qui coûtent un rein.

https://download.qelectrotech.org/qet/f … tation.png

just waiting a happy donator