De-Backer wrote:

Has JSON ever been proposed as a file for the elements?
I am asking this because the search function returns NULL.
Perhaps this can be faster than XML.
It is certainly more readable than XML.

No JSON was not proposed.
Elements file are in xml and will stay xml for the following reasons :
-It's the original file format and everything in the code about element are for xml.
-Elements are embedded in the .qet file and .qet file is xml, we don't embedded a JSON collection inside the xml of the .qet.
-JSON need to write new code and so need lot of time and debbuging.
-Not retrocompatible with xml element file (or have two codes, one for xml another for JSON, a big headache and a big sources of bug and weird behavior)
-I think JSON is not faster than xml (pugi xml vs Qt JSON) and if so I think we will don't gain a lot.
They look the problem come from  how Windows access to file, I search if something like ram disk can improve the loading of collection.
Don't forget even if qet start-up on windows is slow, he is much faster than before since we use pugixml and multithreading..... but I hope we can do better nomicons/wink

De-Backer wrote:

I will first create the doc on my PC and then I will forward it there to you.
I think that can work..

it will be plain .txt text.

Whoo it's a hard job, good luck nomicons/smile and thanks in advance

De-Backer wrote:

and what if we index when we open the folder.
instead of everything at start up?

We load all the collection at the start up for use the search engine. If we not do that the search engine will search only for folder already expanded.
Exactly in the sources code, at the start up of Qet we get all files of the element collection and on each of these files we get the name and the information of the element and that all.
The icon of the element are created when the folder is expanded for both speed up the start of qet and limit the memory foot print of qet.
So load only expanded folder could be a great solution (qelectrotech will start instantly) but we lose the search engine.
A solution could to add in each folder a new file with inside the name and information of each element present in the folder but :
1: we must to write new code for that instead of improve existing (And in current state of devel for the 0.8 I don't make big change, I polish existing before the release)
2: We also write code to update these new files with :
-automatic update when add/remove/update new element
-and manual update if a change are made outside of qet)

May be we will do this in future but I prefer to find a magic solution for improve existing code.

De-Backer wrote:

QElectroTech isn't alone in using file / element strategy
-KiCAD
    footprints +10500 file's in 151 folder's
    packages3D +11400 file's in 100 folder's
    symbols 490 file's in 23 folder's => multiple element per file maybe there is performance problem after all
-eagle
    symbols => multiple element per file maybe there is performance problem after all
   
I will check with the neighbors (KiCAD) if they are also bothered by this and how this has been remedied.

Has SQLite been considered for the element?

Or maybe we should also put multiple elements in 1 file.

May be one file for multiple element should be a good way, but the code of qet isn't write for that and write something to handle this will take a lot lot of time and make code very un-understandable, so no.

We already use a sqlite db for element icon in the widget of element collection, but the default is that Qt sqlite isn't multithreade and in definitive load is faster without the db even in linux.

I'm playing with a win10 vm, for the moment I find nothing to improve file access.....
I you have some links about how Kicad or other softwares load multiple files I will be glade to read it.
Not easy this problem.

No, this part of code is used when you drag an element from the common collection to the user collection and so is not called when the collection is loaded or when user drag and drop element into the folio.

C'est corrigé

Oui je vais regarder ça.
Il faudrait que ce soit en fonction de la local

Le dernier comit devrais régler le problème, à essayer.

Actuellement ce n'est pas pris en compte pour l'export du bon de commande.
Il faut que je refasse la fonctionnalité pour qu'elle fonctionne sur la bdd interne du projet.
En attendant tu peut toujours créé une requête perso.

Fixed.
De-Backer, you was in the good way, it was the good line and the good comit wich broke the formula. nomicons/wink

I will see that tomorrow

S.DEFFAUX : https://qelectrotech.org/forum/viewtopi … 227#p12227
Je vient de forcer mon affichage pour être à la même définition et tout va bien, le dialogue est plus petit que l'écran et il est redimensionnable.
Ce qui est étrange sur ta capture d'écran, c'est que le dialogue est anormalement très large.
D'autres peuvent ils confirmé ce problème ?

scorpion810 wrote:

fix bad fonts rendering.

Cool, j’espère qu'au passage ça corrigera quelque bug et crash propre à windows.

Pour info,
J'ai regardé vite fait pour mettre en place le sommaire de la même manière que la nomenclature.
A vue d’œil 80% du code de la nomenclature sera partagé avec celui du sommaire, donc les choses devrais aller assez vite (relatif à mon temps libre nomicons/wink )

S.DEFFAUX wrote:

Non j'arrive pas à le reduire, il a meme tendance a sortir de l'écran et obliger de faire crtl+alt+supr pour fermer QET

Étrange, je vais regarder ça.

Quand tu ouvre le dialogue il a cette taille la par défaut ?
Tu peut quand même le redimensionner par la suite ?
Car chez moi par défaut il est plus petit (même en prenant en compte que mon écran à une définition plus grande) et je peut encore le réduire, il devient alors très petit et doit pouvoir être affichable sur n'importe qu'elle définition d'écran.

Merci nomicons/smile

-Hop les nomenclatures sont terminé.
Vous pouvez torturer le truc dans tous les sens et me remonter les coquilles et petite amélioration si vous en avez.

Petit résumé rapide des fonctionnalités:

Tableau :
-Les tableaux peuvent avoir un nom.
-Peut être ajouté sur n'importe qu'elle folio.
-Police marge et alignement (droite centre gauche) ajustable séparément pour les en têtes et les cellules du tableau.
-Position taille et nombre de lignes ajustable.
-Possibilité de liée plusieurs tableaux entre eux notamment quand l'intégralité de la nomenclature ne peut être contenu dans un folio.
-Ajustement automatique de la taille du tableau par rapport au folio.
-Option pour appliquer la géométrie d'un tableaux à tous les tableau liée à celui-ci, histoire que tout soit homogène.

Contenu du tableau :
-Entièrement personnalisable, vous affiché ce que vous voulez ou vous voulez (info à afficher dans l'ordre voulue, filtre sur type d'élément, filtre sur contenu de l'info "contient, contient pas, non vide etc...").
-Le contenue étant généré depuis une bdd sqlite, il vous est possible d'écrire votre propre requête.

Dialogue de création de nomenclature.
-Sauvegarde/chargement de configuration du tableau et du contenue afin de rendre la création plus rapide.
-Option pour automatiquement ajuster le tableau au folio.
-Option pour ajouter automatiquement de nouveau tableaux dans de nouveau folios si la nomenclature ne peut être contenue dans 1 à N folios/tableaux.

Corrigé merci.

galexis wrote:

Si tu te ressers de ce tableau comme fonction pour lister les folios, les sections de fils ou autre et les câbles,ou un autre cas qui pourrait le nécessiter ...

Oui ce sera le cas, et donc ? Dans ce cas tu serais plutôt pour le 3 ?

Question sur un comportement :
Quand on supprime un tableau qui est liée à d'autre tableau, faut il :
-1 supprimer uniquement le tableau
-2 supprimer tous les tableaux liée à celui-ci
-3 poser la question.

Perso je penche pour le 2eme car je pense que cela évitera des erreurs du style oublier d'en enlever un.
Ça n'a aucun sens de supprimer un tableau et garder les autres qui étais liée car que l'on supprime un tableau du début, de fin, ou au milieu dans tous les cas il manquera des infos étant donné qu'il manquera un tableau ou alors (en fonction de la config) le dernier sera beaucoup plus gros et donc dépassera du folio.
Et pour finir mettre en place des tableaux est maintenant assez simple et rapide c'est pas comme si on perdais 1h de boulot..

372

(32 replies, posted in Code)

16  + 20 + 20 = 56s
Wooo less than 1 min to build for three OS.

Hello, thanks for the patch, but in the Qt documentation I see the follwing note:

Note: Since Qt 5.14, range constructors are available for Qt's generic container classes and should be used in place of this method.

for both QList<T> QSet::toList() const and QList<T> QSet::values() const.
May be it's will be better to use range constructor, because values will probably be deprecated in future.

S.DEFFAUX wrote:

Je viens de tester sur Win10, la création de nouveau folio fonctionne bien, par contre la nomenclature dépasse du folio même en cochant la "casse ajuster au folio".

C'est pas normal ça. Le tableau s'adapte en hauteur et en largeur, normalement il y une marge (d'environ) 20 px gauche/haut/droit et une marge en bas dont la taille varie en fonction de la taille du folio et de la hauteur d'une ligne de la nomenclature, mais en aucun cas le tableau ne doit dépasser du folio. Peut tu envoyer ton projet pour que je regarde ?

scorpio810 wrote:

*Les tables sont statiques en ce qui concernent les traductions, donc si vous changez de langue les entêtes ne seront pas automatiquement traduis, faudra générer de nouvelles tables.

Je l'avais oublié celui-la, je vais corriger ça.

Pour le tableau oui c'est faisable, un peu de programmation, ajouter une nouvelle table a la db etc... rien de bien méchant.
Je ferais ça pour la 0.8 en plus de la refonte du sommaire avec le nouveau tableau.