je pense a un faux positif. Ou Windows defender qui fait du zèle ...

https://www.virustotal.com/fr/file/f9ad … 466614236/

en essayant d'installer la dernière version.

je tente sur mon PC 'train' sur lequel j'utilise un autre antivirus (Kaspersky).

je viens de recompiler la version 4556 avec les nouvelles bibliothèques Qt 5.7 pour les paquets Windows, elle est maintenant disponible au téléchargement.

Regarde quand tu pourras, si ça règle le soucis avec les écrans QHD/4K de ton coté, merci.

QElectroTech V 0.51-dev+svn4556
Compilation : GCC 4.9.3 - built with Qt 5.7.0 - run with Qt 5.7.0

Laurent

C'est pour bientôt : http://lists.qt-project.org/pipermail/d … 26162.html
https://wiki.qt.io/Qt_5.6.1_Change_Files

reste plus qu'a attendre la sortie de Qt 5.6.1 et voir si ça corrige le problème que tu rencontres.

Je ne suis pas sur que le souci vienne de QET puisque  cette meme manipulation sur un écran classique ne pose pas ce souci. Je pense plutot un bug du côté de QT 5.6. Les deux fénetres (liaison et affectation sont modale et la derniere à apparaitre est celle de l'affection du nom qui devrait être au-dessus de celle de Liaison . Or avec mon écran QHD ,  c'est l'inverse qui se produit  .

merci du retour, on verra si on peux arranger ça.

Dysfonctionnement observé bien sur la priorisation des fenêtres modales. Lors d'un voyage en train (donc mon écran QHD), j'ai eu à déplacer à modifier des renvois de folios donc délier le renvoi pour le relier ensuite à un autre folio . Quand on fait la liaison au nouveau folio , qet nous offre le choix du nom du conducteur à appliquer . or , cette fenêtre, modale, était sous le formulaire de liaison , m'obligeant à passer par un "ALT+TAB" pour pouvoir la "tuer" (-> la fermer). La même manip sous un écran plus modeste ne pose pas de problème .

Tu peux essayer de désactiver l'ancien panel d’élément et activer le nouveau, et relancer QET. Il est deux à trois fois plus rapide et consomme bien moins de RAM que l'ancien, mais il lui manque encore des fonctions, comme des onglets pour la gestion des cartouches, et des folios du projet, mais plus besoin de rafraîchir la collection quand on modifie un élément, c'est pris en compte à la volée.
Ce qui devrait réduire les envolées de RAM utilisée chez Nuri.

Apres ça dépend aussi du nombre et de la complexité des éléments contenus dans ta collection utilisateur.

Bonjour, dans mon cas, je ne peut pas dire que ça aide beaucoup.Apparemment,je longtemps avec le démarrage de l'éditeur de schémas affiché .

real    0m9.977s
user    0m7.468s
sys     0m0.572s 

Avec l'ancien panel seul : 898 352 k de RAM utilisée
(SDD 840 pro 128 Gio)
[12:08:21] laurent@debian:~$ time qelectrotech
transaction began for  "common"
transaction commited for  "common"
transaction began for  "custom"
transaction commited for  "custom"

real    0m11.357s
user    0m8.684s
sys     0m0.740s

https://wiki.debian.org/ReproducibleBuilds/About

https://tests.reproducible-builds.org/r … otech.html

https://tests.reproducible-builds.org/h … otech.html

https://diffoscope.org/

https://diffoscope.org/examples/https-e … 5.0.7.html

Avant on comparait juste le timestamp des fichiers des collections pour la base de données cache pixmap.
La comparaison était plus rapide car le logiciel n'avait pas besoin d'ouvrir et de lire chaque fichier élément.
Maintenant on compare chaque UUID, ce qui en temps machine est un peu plus long car il faut parcourir l’arborescence de toutes les collections éléments, lire l'attribut XML "UUID" de chaque fichier elmt pour ensuite comparer leurs valeurs avec la base de donnée SQlite.

Certes le moteur SQlite n'est pas le plus rapide, mais un contrôleur et un disque rapide ou SDD rend le démarrage de QET bien plus véloce.

Bonsoir pach30310,
Pour l'instant sous Windows oui, sous GNU/Linux c'est juste une question de jours/semaines le temps que les packageurs intègrent cette version de Qt sur les dépôts.

Merci, n’hésites surtout pas à nous faire remonter ces incongruités, quand tu en rencontreras.
C'est ce style de problème que je redoutais ..., on a parfois des surprises quand on reprend des projets d'un système d’exploitation à un autre (c'est maintenant assez rare), sans compter maintenant le transfert de projet d'une machine 2k à une autre avec écran 4K, et vice versa.

Le même système d'exploitation?

Sur ma VM Seven 64, je trouve les lancements de Qet plus long ( ~ 1.20 min), certes la VM est basée sur un vieux HD et pas sur le SSD mais quand même. Au boulot sur une Debian avec un vieux HD de 160 Gio sata 2 c'est six fois plus rapide...( 26s )

Il semble que le passage en QT 5.6 soit un réel plus pour les écrans haute définition QHD et que l'on peut dire que ca fonctionne correctement (sous window uniquement si j'ai bien compris ) . Sur mon écran, cela devient expoitable et surtout je peux "jouer" avec le même fichier sur différentes machines avec des définitions écrans différentes .
 Je découvrirais certainement quelques comportements surprenants (ex , ce matin , j'ai rajouté un texte dont il a fallu que je modifie la taille à postériori car plus petite qu'un texte ajouté avec un autre machine). Je n'ai pas fait de tests exhaustifs  mais je posterais si j'observe des incongruités

Par contre , j'ai toujours cette lenteur au chargement de l'appli sur mon Yoga 3  (ultrabook): plus de 3 minutes -répétables- pour que l'appli soit lancé malgré un HDD SSD de 512 Go et 8 Go de ram. Une fois lancé, plus de souci. (par ex les appli de MsOffice démarrent quasi instantanément).

Mais bon, cela semble bien particulier à l'architecture de la machine car je n'ai vu d'autre commentaire de ce type sur le forum.