Salut Nuri,
Petites explications du pourquoi de ces nouveautés :
Dans ces améliorations, je pense que tu es comme moi, la seule qui devrait vraiment t'intéresser, elle t'es d'ailleurs dédiée 
: c'est la taille de trait des basic shapes. Ça permet d’étendre les fonctionnalités de QET, de dessiner rapidement une représentation machine légère sans incorporer d'images, ou de sortir l'artillerie lourde avec le convertisseur DXF.
Je préfère dessiner la représentation des coffrets extérieurs en 0.8 pixel sur mes schémas, c'est bien plus classe.
Le problème venait de l'impression sous MS Windows, j'avais mis en place une taille prédéfinie suivant la plateforme détectée, puis plus tard mis tous les OS sur une taille fixe en 1 pixel.
Pour la taille des conducteurs cela nous avaient été souvent demandés, et nous avons toujours rechignés à l'entreprendre, moi le premier.
Mais récemment un [s]client [/s]technicien d'une société dans l'industrie de construction automobile m'a contacté en me demandant de prévoir si possible une feature ou un workaround car sur leurs schémas imprimés en A3, les couleurs des conducteurs n’étaient pas très lisibles, surtout sur le terrain.
La première solution a été de lui envoyer un paquet avec la taille des conducteurs forcés en 2 pixel, ce qui a bien résolut son problème d'impression.
qet-0.5_pen.setwithF2.0_fix_mousehover
C'est après, que je me suis décidé à mettre en place cette fonction pour définir l’épaisseur des conducteurs facilement par l'utilisateur soit pour tous les projets, pour le projet en cours, ou à la volée.
Apres ceux qui veulent différencier les conducteurs par l’épaisseur de trait suivant la puissance c'est maintenant possible, mais c'est une aberration sur les schémas électrotechnique industriel.
Pour les couleurs des basic shapes on sort du cadre normal d'utilisation de nos schémas pour coller à des demandes spécifiques comme pour les coffrets ascenseurs, donc oui ça se fera, quand j'aurai le temps, même si le premier je m'en servirai surement pas.
Du coté de la consommation mémoire, Joshua de son coté est en train de réécrire entièrement le code du panel d’élément.
Travail gigantesque, long, difficile et pénible, mais une fois le code entièrement réécrit et pas disséminé dans tous les recoins comme il l'est actuellement, ce nouveau panel d’éléments devrait rendre l'utilisation de QET méconnaissable sur des machines plus légères et limitées en RAM, et même sur nos petites workstations de développement.
Les premiers tests montrent une baisse d'environ 250 Mio avec les mêmes collections d’éléments, en passant de l'un à l'autre, un rafraîchissement presque instantané lors de l'ajout de nouveaux éléments.
Alors certes pour l'instant sur nos machines sur vitaminées en RAM c'est une peccadille, pas sur les machines modestes qu'on trouvent parfois en entreprise.
Il devrait même ouvrir la voie à des vues de sous dossiers dans les projets comme par exemple sur Eplan, des onglets pour des vues séparés pour les éléments, folios du projet, etc, dans le futur.
R.I.P Ian 
Merci pour tout ce que tu as fait.
https://bits.debian.org/2015/12/mourning-ian-murdock-fr.html
http://blog.docker.com/2015/12/ian-murdock/
