You are not logged in. Please login or register.
Active topics Unanswered topics
Search options (Page 29 of 33)
Now, I can reporduce this bug around 70% of time with your project morganol.
The first strange thing, is that I can't reproduce bug if I follow your procedus.
But if I select the pump and valve move it and delete it, like I say 70% of time a can reproduce the bug.
Bad news, yesterday I spend around 4 hours and I have no idea where this bug come from. It is very very strange.
In the code, when the bug occur, conductor have no QGraphicsScene, the scene have no Conductor, but something call the method paint of the conducteur and I don't know who call this method.
The only good news, I can now reproduce this bug and it's a big step.
PS : I want to say "it's a Qt bug" , but this appear only with conductor so "it's a QET bug"
Corrigé avec le commit 4747.
Par contre ce ne sera pas actif sur les conducteurs déjà existants.
Il faudra corriger la valeur avec le dialogue de propriété du conducteur et sauvegarder.
Les réouvertures suivantes n'auront pas de problème.
Si vous voulez plus d'explications faite moi signe.
Be carefull, this commit can solve this crash, but I'm not sure, because we can't reproduce it every time.
The only thing I'm sure, QUndoCommand is now used as recommended by the Qt documentation, and the part of the source code where I make this change is related with the element/conductor/conductor autonum.
Only long test can say if "yes this bug is fixed".
Twist your fingers and hope this bug is an old story
Crash fixed with commit N° 4736. Thanks for the report
Arf c'est vraiment ennuyeux, ce foutue crash qui arrive lorsque il y a des artefacts de fils ou basic shape supprimé.
Sa m'est déjà arriver en cours de développement mais je n'ai jamais réussi à trouver la source du problème car toujours aléatoire. Et cela fait maintenant un moment que je n'ai pas rencontré ce bug.
N'hésiter pas à remonter toutes les info disponible sur ce bug afin que l'on puisse le régler le plus vite.
scorpio810 wrote:nuri wrote:Peu importe si l'utilisateur emploie des variables ou écrit directement, il ne faut pas faire comme ca !
C'est ce que je voulais dire avec "= et + n'ont rien à faire dans le champ label".
L'idéal serait d'avoir le widget "propriétés de la sélection" comme ceci :
Heuu, là tu nous compliques beaucoup la vie d'un coup 
, et ça va à contre sens des commits de Davi et des miens.
Je pense qu'il te faudra t'y habituer et faire Label = %M-%LM-M1, et même si je pense que tu as raison et que c'est bien plus logique, le code ne se change pas en trois coups de cuillère à pot. 
Ba pour le coup, vous avez inclue énormément de variable Davi et toi (ce qui est bien).
Mais pour l'histoire des + =, comme je l'avais déjà expliqué cela sera géré par le projet lui même (pas les folios ni les cartouches).
Ainsi si un folio se trouve être dans =G01 +L01, il va de soi que tout les éléments présent dans ce folio le sont aussi (ce qui rend les choses nettement plus rapide que de renseigner individuellement chaque éléments) à l'exception des éléments appartenant à une autre localisation, qui seront déterminé explicitement, par exemple en les entourant d'un cadre.
Du fait, une fois ce système mis en place les actuelles variables de localisation seront inutile (à moins de changer leurs comportement, et d'aller chercher directement les info dans le nouveau système).
scorpio810 wrote:Revision: 4576
Author: blacksun
Date: 2016-07-14 13:58:56 +0200 (Thu, 14 Jul 2016)
Log Message:
-----------
ElementsCollectionModel : model use multithreading itself for load collections
Qet utilise maintenant tous vos cœurs CPU pour charger plus rapidement vos gros projets.
Petite précision, il s'agit toujours du chargement des collections d'éléments. Les projets n'utilisent pas le multithreading.
Content de lire ça. La refonte du panel porte ses fruits
Bonjour,
Merci de nous remonter ce bug, afin de rendre qet plus stable.
Hélas nous n'arrivons pas à le reproduire, ce qui rend très difficile d'en trouver la cause.
Néanmoins, j'ai fait un petit hack sur ma version de développement, et j'ai pu récupéré environ 90% de votre schéma.
Nuri wrote:Pareil chez moi sous Ubuntu avec l'intel i7-4750HQ, pas le temps de voir le splash. Par contre, le chargement des collections ne se fait plus en arrière plan et je peux maintenant voir la barre de chargement.
Avant, le chargement de la collection se faisais pendant le splash screen.
À présent, il se fait lors de l'affichage de la fenêtre principal, l'utilisateur voit mieux ce qu'il se passe.
Nuri wrote:Petite différence avec Laurent :
je viens d'installer le dernier build Windows en VM avec Win10. La VM utilisant seulement 2 cores du CPU parmi les 4 disponibles, le chargement est aussi très rapide.
Petite démo :
Tu me rassure, comme Laurent je commençais à me poser des questions (et en plus installé une VM pour tester sous windows.....).
Le prochain commit sera probablement une amélioration des recherches dans le panel d'élément.
Actuellement quand on cherche par ex omron, le champ bloque bloque sur le o puis mron s'écrit plus tard, y'a quelque secondes ou qet mouline. J'ai mis le doigt sur le problème, bientôt corrigé.
Nuri qu'elle est ton thème d’icône sur ubuntu?
C'est la première fois que je voie une icône de qet dans un thème.
scorpio810 wrote:galexis wrote:Avec l'autre panel, je n'avais pas de soucis.
Ça m'étonne un peu, ce fonctionnement n'est pas propre au nouvel panel.
Le fonctionnement est le même, mais j'ai retoucher le bout de code qui gère ça (dans la class QetProject). Donc il est possible qu'un bug s'y soit glissé.
Cela dit, ce que montre Laurent dans la vidéo est le comportement normal de QET.
Actuellement la fonction nettoyage ne fait rien.
Elle étais active avec l'ancien panel, mais n'a pas été implémenté dans le nouveau.
J'ai volontairement mis de coté cet fonction "secondaire" (qui reviendra ne vous inquiétez pas) afin de sortir le nouveau panel le plus rapidement possible.
Oui, au premier lancement la bdd est inexistante, donc celle ci est crée et remplis durant le démarrage ce qui effectivement est très long.
Bravo Laurent, c'est une bonne nouvelle 
Le problème est en partie réglé.
"Enregistrer" fonctionne à nouveau lors de la création d'un nouvel élément.
En revanche "enregistrer sous" est encore inactif selon l'action effectué.
Le correctif viendra plus tard (la correction nécessite plus de travail que pour "enregistrer").
Pour le coup ont pas faire grand chose car c'est Qt lui même qui gère l'ensemble de cette fenêtre.
Mais j'avais déjà remarqué que sur ma debian le dialogue "natif gnome3" n’étais plus utilisé non plus (A la place j'ai un dialogue tout moche). Peut être la version de Qt ?
Salut pach, merci pour les encouragements ça nous fait toujours très plaisir.
Il attendait de déménager et d’être installé, en espérant qu'il ai choisi un écran HDPI ....
Et non je n'ai pas de HDPI seulement un Samsung S24D340 (dont j'en suis très satisfait, et remercie les personnes ayant fait des dons permettant l'achat de cette écran).
Visiblement l'option Qt::AA_EnableHighDpiScaling semble bien marché, je n'ai pas lue la doc de Qt au sujet des écrans 4k mais je me doutais bien que Qt pouvais faire ça tout seul.
J'ai bossé aujourd'hui avec la v0.5 RC 1 qui semble stable (pas eu de plantage ). Par contre , sur mon perso (W10 X64/8Go ), très gourmand en RAM alors que je n'ai rien remarqué au boulot (W7 Ent W64,4Go Ram)
Je travail actuellement sur la baisse de conso ram (un gain de plusieurs centaines de Mo) même si visiblement ton problème ne vient pas la.
Bien vue
corrigé.
scorpio810 wrote:en plus de réduire la consommation RAM.
Alors oui, la conso ram devrait beaucoup baisser, mais le panel d'élément n'est qu'une partie du problème, après avoir fini le panel d'élément (qui est déjà bien avancé), il reste la partie immergé de l'iceberg...
Nuri wrote:scorpio810 wrote:Regarde les liens sur la doc Qt qabstractitemmodel, The model/view architecture.
wi wi, j'ai déjà mangé ca :
https://openclassrooms.com/courses/programmez-avec-le-langage-c/l-architecture-mvc-avec-les-widgets-complexes
La doc Qt je commence à comprendre, ca me paraît pas impossible. Le problème c'est les lacunes C++... Que dis-je... les trous noirs en C++.
La finalité du nouveau panel sera-t-elle aussi d'intégrer l'arbo du projet dedans ou non ?
Pour l'instant, les onglets ca me va bien.
Euh.. je vais formuler autrement :
Est-ce qu'à terme les projets seront dans le même QDockWidget que les collecs ou dans un autre ?
Même question .... ;-)
La collection d'élément restera seul dans sont QDockWidget, l'arborescence du projet sera dans un autre QDockWidget, surtout quand il y aura les =/+, ce sera pas superflus.
scorpio810 wrote:Oui, avec des onglets, mais surtout une plus grande facilité d’insérer un nouveau folio là ou l'on le veut, voir même un déplacement d'un ensemble de folios, pouvoir aussi découper l’arborescence du projet en sous dossiers comme sur ton Eplan adoré.
Mais bon, je m'avance un peu, seul Joshua travaille dessus, et est à même de vous répondre correctement de ce qu'il sera possible de faire, ou pas.
Du point de vue de l'arbre (QTreeView) beaucoup de chose sont possible (je dit pas que c'est toujours simple à coder). Mais la plus grosse difficulté sera de créer un "cahier des charges" et de mettre ça en œuvre dans QET, car comme à dit nuri, "ça sous entend de refaire tout le système des ref croisées" mais pas que...
Salut, essai le commit 4355, voir si ça te conviens.
Bonjours, la borne de ton élément est sûrement mal positionné.
https://download.qelectrotech.org/qet/joshua/bornes-decal%C3%A9.png
Sur le lien, par rapport au trait la borne de gauche est bien placé tandis que celle de droite donnera le même problème que tu as.
(Les bornes sont décalé des traits uniquement pour comprendre, en réalité celle ci doivent superposer les traits)
Maintenant que les traits sont fait, je peut aussi faire le remplissage, surtout avec le petit bout de code pour générer le xml correspondant au QPen utilisé, il est très petit et très simple, mais rend bien service.
Donc si c'est un "petit truc" qui peut être utile de temps en temps, je peut mettre le remplissage des shapes dans ma todo list.
Pour le patch, c'est pas pour l’intégrer dans la 0,5 car il y aurais beaucoup plus de boulot.
C'est juste pour vous afin d'essayé avec vos projet, et si la conso ram baisse alors sa m'aiguille sur l'origine du problème.
Bon le comparatif avec une vidéo bof, une vidéo est compressé avec des algos très très complexe, alors que dans qet rien n'est compressé. Cela dit, j'avoue que garder en mémoire des QLineF, QRectF et compagnie ça doit pas prendre des quantité astronomique de ram.
La 0,6 sera orienté sur ce problème qui deviens de plus en plus contraignant.
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.
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.
Posts found: 701 to 725 of 819
Generated in 0.017 seconds (47% PHP - 53% DB) with 6 queries
