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

 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 nomicons/wink 
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)

Nuri wrote:

Reste plus que le remplissage des basic shapes nomicons/ninja nomicons/alien nomicons/tongue nomicons/devil

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.

712

(36 replies, posted in News)

Non rien de nouveau pour les câbles, le code n'a pas bougé depuis la vidéo.
En fait dans la vidéo le code ne fait pas grand chose, juste posé les traits en diagonal sur chaque câble (même le texte dans l'encadré sur la seconde vidéo est écrit en dure, à l'exception du nombre de conducteur).
Donc pour faire une vrai fonction "câble" il reste énormément de boulot.
Par contre toute les idées/demandes/attentes au sujet des câbles sont la bienvenue.

Bonjour Laurent,
oui je connais ce bug, c'est liée à un élément ou alors un conducteur qui c'est trouvé un à moment donné à l’extérieur du cadre du schéma.
Qet fait en sorte que l'on puisse toujours voir tout ce qui est sur le schéma (même les choses en dehors du cadre) d’où les marges, c'est gênant mais ne provoque pas de crash, et l'impression reste correct.

Je confirme, j'ai les mêmes problème sous win7, voir même pire, je supprime un renvoie déjà lié avec un conducteur -> crash direct....
J'ai aussi des problèmes avec les formes (polyligne) je la supprime puis fait un undo et la, il y a des comportements bizarre.
Je vais voir ce qui se passe sous ma debian.

Attention galexis, je vois que vous parlez d'uuid et d'id, qui sont deux choses différentes.
Les ID des bornes, pas les éléments bornier, mais bien les trucs bleu et rouge qui servent à posée les conducteurs (je le précise pour que l'on parle bien de la même chose), servent comme Laurent l'a expliqué à savoir sur quelle bornes est relié un conducteur.
Cela sert uniquement quand on charge un projet depuis un fichier, en utilisation, on à d'autre moyen de le savoir.
Petit précision, les ID ne sont pas fixe d'une sauvegarde à l'autre. C'est à dire que tu peut sauvegarder ton projet, une borne se verra attribué l'ID 1. Tu ferme/ouvre le projet, travail dessus puis sauvegarde, cette même borne qui portait auparavant l'ID 1 peut tout à fait porter l'ID 32, car les ID sont attribué lors de la sauvegarde.
Pour finir, les ID sont bien crée par folio, donc sur un projet de 100 pages tu aura 100 ID 0 (1 par folio).

Pour les uuid cela n'a rien à voir avec les conducteur ou bornes.

Wahou, bravo Nuri nomicons/wink

717

(13 replies, posted in News)

Tu as juste à poser un élément de la collection officiel (collection patché avec les uuid) déjà existant dans ton projet (par ex une bobine) normalement tu devrais avoir le dialogue signalant que l'élément est déjà intégré, mais semble différent.
A cette question tu coche "écraser", ce qui aura pour effet de remplacer l'ancien élément par le nouveau (donc avec les uuid).
Fait une copie de ton projet avant quand même nomicons/smile .

Techniquement, ce n'est pas possible en l'état actuel des choses, car les textes de conducteurs sont de simples textes même quand ils ont été créés, par le biais d'une auto-numérotation.

Je m'explique :

si ton autonum est de la forme suivante dans le folio 3 : folio + texte fixe (S) + variable numeric (0).

cela prendra la forme pour les conducteurs :

N°1 : 3S0 | N°2 : 3S1 | N°3 : 3S2 etc...

Lorsque l'autonum est sollicité pour créer une nouvelle num, elle construit un texte en fonction des variables, puis renvoie le texte ainsi créé (au conducteur dans notre cas). Pour finir, le conducteur applique le texte sans aucune idée de la manière dont il à été créé.

Cela veut aussi dire, que si l'on crée ta demande, cela ne pourra-t-être retro-actif sur des projets déjà existants.

-Autre petit problème : comment gérer le truc quand tu as des conducteurs présents sur plusieurs folios ?

Pour finir je comprend la demande, mais je ne pourrais la faire actuellement pour plusieurs raisons:

-Autre fonction prioritaire

-Certaines fonctions qui sont actuellement dans les cartons, risque de rentrer en conflit avec ce système, il serait préférable de voir pour mettre en place ce système une fois les fonctions mentionnées "créées".

Bonjour,
Pour les questions de nuri :

1° - Il s'agit clairement d'un bug ou défaut, donc il faut que je vois cela.

2° - Pour la stabilité du dock, je ne peux pas dire aussi sûrement que Laurent, qu'il l'est. Seul les retours le rendront plus stable. (Pour info, le dock et les widgets qui sont "insérés" dedans sont deux choses distinctes, cela veut dire qu'il peut y avoir un bug dans l'édition des éléments mais pas celui des images, car ce sont deux widgets différents).
-Pour les dialogues, perso je pense les laisser pour plusieurs raisons:
*Ils sont déjà présents.
*Ils ne représentent pas une masse de code supplémentaire.
*Par expérience, il vaut mieux laisser le choix à l'utilisateur (je pense que chacun utilise qet de manière plus ou moins différente). Et je suis prêt à parier que si je les enlèves, on me demandera de les remettre.
Après il peut-être envisageable de créer une option qui désactive les dialogues quand ils existent aussi dans le dock (comme disait Laurent)

3° - Actuellement, par défaut il se trouve à droite, car:
*C'est comme ça que je l'ai codé.
*On retrouve souvent ce genre de dock (édition de la sélection) à droite dans différent logiciel. (j'ai donc suivie une pratique commune).
*C'est moi qui code, c'est moi qui commande (bon j'avoue c'est pas une bonne raison :p )
Après, savoir ou le mettre par défaut c'est un sujet probablement sans réponse, car chacun aura ça préférence.
Pour ma part, je ne propose rien pour les raisons évoquées.
De toutes manières Qt permet de poser le dock où l'on veut par la suite et c'est sauvegardé dans la conf.

Hello marker,
For the moment we have a lot of more important feature to do.
The feature you describe is good but for now we can't do it (the road map is big, we are a small team, so we focus to the important functionalities).
Best regards joshua.

721

(86 replies, posted in News)

J'ai pas fait attention aux check box, je m'en occupe.
Je vais aussi faire (j'ai encore pas touché au code, mais c'est bien réfléchie) le merge des undo des link/unlink élément quand c'est possible. De la même manière des info d'élément, quand on remplie les info, il n'y a qu'un seul undo (et non pas un pour chaque lettre....)

722

(86 replies, posted in News)

Je l'ai fait en rapide celui des master element, car en fait j'ai pas fait tout ce dont je voulais faire....
mais j'y reviendrais après avoir fait les info, car pour l'instant c'est utilisable.

Perso,
je me voyais bien faire comme la page 1 et 3 du pdf de Nuri. Après en fonction des demandes ça peut évoluer bien entendue.
Ensuite comme à dit Nuri, il faut bien distingué deux choses.

1° la partie Data.
2° la partie graphique.

(je prend ma casquette de développeur....)
Il me faut avant tout connaître de manière claire (En d'autres mots vos attentes) toute ce qui doit figurer dans la partie data, car c'est le plus important.
Ensuite vient la partie graphique qui  est (j'exagère un peu) juste la mise en page des data, et cela vient après dans le résonnement.

Donc pour faire avancer le truc (même si c'est pas pour tout de suite) mettez à plat tout les choses correspondant à la partie data.

Laurent au sujet du plugin python rêve pas trop ..... nomicons/smile  faire des plugin C++ pourquoi pas car Qt le permet out of the box (mais faut avoir une base bien clean avec certain prérequis, enfin bref je m'égare la...) en revanche pour le python c'est pas trop le cas et je pense qu'on dépasse mes connaissances....

Cela dit l'idée est très bonnes même si c'est plutôt l'inverse au niveau du résonnement car le coté data Qet le connais donc suffit juste de fournir toutes les info au plugins, par contre le coté graphique peut être fait de plusieurs manière différente surtout au niveau des options (barrette de jonction, ajouté un ou deux bornier de plus ect....).
Et la le plugins peut être sympa car c'est lui qui ferait tout ça et il renvoie juste un pixmap qu'on intègre dans les folios.

Une dernière choses, pour moi je verrais bien les borniers en post traitement, c'est à dire pas de mise à jour lors d'une suppression/modif/déplacement (en gros ce serais juste une image, voir réellement une image).
Pour les raisons suivante.
-Gros truc et usine à gaz à codé (comparé au post traitement)
-fort risque d'erreur, en post traitement les erreurs serais toujours possible (et oui je fournis beaucoup de bug) mais très minimisé étant donné qu'on récupère les data à un moment T, donc si c'elle ci sont bien interprété et mise en page y'a pas de raison.

L’inconveniant c'est qu'il faut refaire le bornier si on touche au schéma, mais en principe on fait ça à la fin donc bon....

A+

724

(86 replies, posted in News)

Pour l'instant seul les esclaves (contact) et renvoie de folio fonctionne à la volé (car en fait c'est le même widget).
Le prochain sera les maîtres (mais y'a un peu plus de taff).

Il s'agit bien d'un bug (de ma part nomicons/unsure )
Réglé dans la révision 3833.
Merci du retour.