Search options (Page 234 of 293)

Tu peux le repositionner précisément avec la touche ctrl s'il a bougé.

Uhuhu, tu devrais voir un gros changement avec les versions de la 0.5 par rapport à la vieille 0.22.
Vouine, c'est quoi ce truc?

Je pense qu'on vas quand même faire une RC de plus, surtout parce que j'ai pas le temps, et surtout même pas commencé à préparer l’écriture de la dépêche là concernant. 
Par contre ce serait bien, si tu pouvais me filer un coup de main pour sa traduction en anglais et allemand si tu le souhaites.

Pour moi, la gestion des =/+/- sur un seul niveau, tu peux déjà te dépatouiller comme le fait déjà Nuri.
Le gérer comme le font Eplan et autres logiciels sur plusieurs niveaux, demanderait à revoir le code de Qet de fond en comble, ce qui est loin d’être une sinécure et agréable à entreprendre maintenant! Au risque de décourager tout le monde, les dev y compris, pendant un temps qui pourrait être très long!

Ceux qui ont besoin des découpages =/+/- sur plusieurs niveaux sont prêt à payer plus de 15 000€ leur logiciel de schémas, plus les abonnements annuels (schémas de lignes entières dans l'automobile, l'aviation, la pharmaceutique, etc). Ils font payer aussi très très cher leurs schémas, je pense pas qu'ils s’intéressent, même de loin à un logiciel comme QET!

Le projet doit maintenant approcher les 100 000 lignes environ, dont 50 000 de C++, tout reprendre demanderai d'avoir des personnes à temps plein et payés rien que pour ça, pas comme nous sur notre temps libre, avec nos petits moyens!

https://www.openhub.net/p/qelectrotech

En ce moment Joshua est presque seul sur le code, avec une moindre participation de ma part : moins de temps pour le code, beaucoup à faire à coté (serveurs, packaging Windows et Gnu/linux Debian, maintenance mail, forum et irc, gestion du projet, management, et code de plus en plus complexe, etc).

Ça me rappelle quand Xavier s'est lancé sur les cartouches, silence radio ou presque pendant plus d'un an et demi sur les commits.
Le cycle des releases approchait les 3 ans, avec très peu de features intéressantes pour le commun, et à force le découragement c'est fait sentir.... vous connaissez la suite.

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

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.

Merci du retour, pas mal de nettoyage de code et autres améliorations ont été effectués depuis la RC1, pas spécifiquement sur l’éditeur et ton problème, mais ça vaut toujours le coup de tester avec les derniers builds.

Il me semble qu'a une époque, j'avais eu ce style de désagrément avec des symboles dessinés sous Windows au boulot, et parfois décalés une fois lu sur ma Debian en rentrant !

Le démarrage on s'en fout un peu Joshua : surtout maintenant avec les sdd sata, avec les ssd PCI-Express NVMe ça devrait aller encore plus vite, si on ajoutent la gestion des threads sur le cachedb pour exploiter tous les cores cpu:  le premier chargement des collections n'en sera que plus rapide, en principe.
Une fois le cache pixmap (cachedb) déjà à jour, le lancement de Qet complet prend dans les 7 secondes sur cette machine.

[05:03:11] laurent@debian:~$ time qelectrotech
transaction began for  "common"
transaction commited for  "common"
transaction began for  "custom"
transaction commited for  "custom"

real    0m7.007s
user    0m4.704s
sys     0m0.496s

C'est le chargement des gros projets en mémoire (+ 500 folios) qui en seraient fortement accélérés, avec une consommation mémoire grandement divisée, avec ta solution, si tu y arrives.

Exemple :lancement de Qet, et chargement d'un projet de ~120 folios assez lourd : (multiples images, très nombreuses définitions de symboles, plusieurs milliers d’éléments), un seul core est actif, avec la gestion du multithread  on gagnerai sur les temps de chargement: ~40 secondes (lancement de Qet et du projet ~ 120 folios : jusqu’à être prêt à dessiner) sur la machine de build. Sur une machine moins musclée, ça prend effectivement beaucoup plus de temps.

[05:03:30] laurent@debian:~$ time qelectrotech
transaction began for  "common"
transaction commited for  "common"
transaction began for  "custom"
transaction commited for  "custom"


real    0m39.601s
user    0m33.668s
sys     0m1.168s

Je vous faits grâce des acces disques 

video

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.

Clair, je viens de tester sur de mes vieux projet de ~115 folios : à chaque action sur la touche F5 (recharger les collections) la RAM utilisée peut augmenter de plus 100 à 200MIo à chaque fois.

Le problème est connu, surtout lors du premier lancement de Qet ou la génération de la base de donnée des miniatures peut consommer plus d'un 1.5GIo de ram avec une collection de ~2600 éléments, pareillement quand on change la langue du programme et donc aussi des elements. Il est d'ailleurs conseiller de fermer et de relancer Qet dans ces cas!

Je te dirai bien dans l'onglet conf de régler le "save path" vers le chemin de ta collection personnelle, mais les elmt fraîchement convertis ne sont pas encore prêt à être placés directement dans les folios.
Il faut les ouvrir avec l’éditeur : l’éditeur ajoutera automatiquement la bonne valeur au hotspot à la sauvegarde!