Re: Nouveautés de la version de développement 0.8
Pour info j'ai commencé la rédaction d'une dépêche sur linux fr pour la sortie de la 0.8.
Tout le monde peut y participer
You are not logged in. Please login or register.
QElectroTech → News → Nouveautés de la version de développement 0.8
Pour info j'ai commencé la rédaction d'une dépêche sur linux fr pour la sortie de la 0.8.
Tout le monde peut y participer
Merci à tous. Cette dernière version fonctionne bien, le chargement des éléments est plus rapide.
Génial merci
QElectroTech V 0.80-DEV+49b2e4ad0c957a06d79751d3
Compilation : GCC 9.3.0
Built with Qt 5.15.0 - Date : Nov 9 2020 : 05:49:37
Run with Qt 5.15.0 using 4 thread(s)
CPU : NAME AMD A10-7860K RADEON R7, 12 COMPUTE CORES 4C+8G
RAM Total : 14806 MB
RAM Available : 10971 MB
GPU : VideoProcessor AMD Radeon Graphics Processor (0x130F)
GPU RAM : RAM Total : AdapterRAM 1073741824 B
OS : winnt - x86_64 - Version : Windows 8.1 Version 6.3 (Build 9600) - Kernel : 6.3.9600
*** Qt screens ***
( 1 : 1920 x 1080 )
Merci à tous. Cette dernière version fonctionne bien, le chargement des éléments est plus rapide.
Génial merci
QElectroTech V 0.80-DEV+49b2e4ad0c957a06d79751d3
Compilation : GCC 9.3.0
Built with Qt 5.15.0 - Date : Nov 9 2020 : 05:49:37
Run with Qt 5.15.0 using 4 thread(s)
CPU : NAME AMD A10-7860K RADEON R7, 12 COMPUTE CORES 4C+8G
RAM Total : 14806 MB
RAM Available : 10971 MB
GPU : VideoProcessor AMD Radeon Graphics Processor (0x130F)
GPU RAM : RAM Total : AdapterRAM 1073741824 B
OS : winnt - x86_64 - Version : Windows 8.1 Version 6.3 (Build 9600) - Kernel : 6.3.9600
*** Qt screens ***
( 1 : 1920 x 1080 )
Chargement plus rapide sous linux. Je testerais la semaine prochaine sous windows.
Avec la readytouse sous win32 : 1er chargement 1min23s et ensuite 30s sur les suivants. Le gain semble là.
Je viens de vois les derniers commit de Joshua dans lesquels il supprime plein d'éléments constructeur en "doublon".
Je me sert beaucoup de ces éléments car les info, "constructeur", "référence" ... sont déjà rentré. Suis-je le seul dans ce cas?
Je viens de vois les derniers commit de Joshua dans lesquels il supprime plein d'éléments constructeur en "doublon".
Je me sert beaucoup de ces éléments car les info, "constructeur", "référence" ... sont déjà rentré. Suis-je le seul dans ce cas?
Je viens de vois les derniers commit de Joshua dans lesquels il supprime plein d'éléments constructeur en "doublon".
Je me sert beaucoup de ces éléments car les info, "constructeur", "référence" ... sont déjà rentré. Suis-je le seul dans ce cas?
Perso, je ne pense pas qu'il faille multiplié les symboles identiques juste pour avoir des références différentes. Elle doit rester générique, et la gestion de catalogue constructeur est une autre fonction, qui n'est pas encore développée. Cela doit rester dans la bibliothèque perso.
so it would be helpful if the elements are split into an image and data?
emm =» https://qelectrotech.org/forum/viewtopi … 325#p13325
so it would be helpful if the elements are split into an image and data?
emm =» https://qelectrotech.org/forum/viewtopi … 325#p13325
I think too ... It's two different things : library and builder database
it would appear that Laurent has released the release candidate
https://git.tuxfamily.org/qet/qet.git/c … 865f67776a
https://git.tuxfamily.org/qet/qet.git/tag/?id=0.8.rc
Last chance to find bugs.
S.DEFFAUX wrote:Je viens de vois les derniers commit de Joshua dans lesquels il supprime plein d'éléments constructeur en "doublon".
Je me sert beaucoup de ces éléments car les info, "constructeur", "référence" ... sont déjà rentré. Suis-je le seul dans ce cas?Perso, je ne pense pas qu'il faille multiplié les symboles identiques juste pour avoir des références différentes. Elle doit rester générique, et la gestion de catalogue constructeur est une autre fonction, qui n'est pas encore développée. Cela doit rester dans la bibliothèque perso.
C'est bête de perdre le travail effectué sur ces symboles, il faudrait conserver certains éléments supprimés par Joshua sur un nouveau dépôt Github, qu'en pensez vous?
J'ai crée un nouveau dépôt et mis dessus quelques symboles supprimés récemment qui peuvent être utiles.
https://github.com/qelectrotech/qelectr … nt-contrib
Si vous voyez des symboles qui ont été supprimés mais utiles n’hésitez pas a faire un pull request.
Oui j'ai supprimé les éléments car en doublons uniquement pour des références. Alors bien sur je comprend que cela fait gagné beaucoup de temps donc un dépôt contrib est la bonne solution.
Je ferais un PR sur le nouveau dépôts si je supprime d'autre éléments.
Oui j'ai supprimé les éléments car en doublons uniquement pour des références. Alors bien sur je comprend que cela fait gagné beaucoup de temps donc un dépôt contrib est la bonne solution.
Je ferais un PR sur le nouveau dépôts si je supprime d'autre éléments.
joshua, can I have a look to create svg in the element
and further customize the element
to a graphic and a data lib?
I would therefore remove the elements from the repo
splits the repo into the source code and elements
but this idea still needs some time..
draft: convert script
# make submodule qelectrotech-elements of the qelectrotech-source
git clone https://github.com/De-Backer/qelectrotech-source-mirror.git qelectrotech-elements
cd qelectrotech-elements
# remove all (git and file's) except elements dir
# note! see: https://git-scm.com/docs/git-filter-branch
git filter-branch --prune-empty --subdirectory-filter elements/ -- master
git remote add https://github.com/De-Backer/qelectrotech-elements.git
git push qelectrotech-elements master
cd .
to create a submodule for the elements I'm still in doubt, why: "git filter-branch" is a git history rewrite tool
see: https://github.com/De-Backer/qelectrote … its/master
for the result
instead of 1 repo with elements I want to extend this to multiple repo's
eg: https://docs.librepcb.org/#gettingstart … ries-local
a repo then contains elements and manufacturers data eg:
data elements
- uuid
- svg =>line... (svg file)
- dynamic_text
* orientation
* X
* Y
* uuid
- terminal
* orientation
* X
* Y
* uuid
data manufacturers
- uuid element
* uuid manufacturer
° names
° elementInformations
° uuid dynamic_text
> data
° uuid terminal
> naam
* uuid manufacturer
° names
° elementInformations
° uuid dynamic_text
> data
° uuid terminal
> naam
update
if you store the "uuid manufacturer" in the schematic
then you can link everything
or:
data elements
- uuid
- svg =>line...(svg file)
data manufacturers
- uuid manufacturer
*uuid element
° names
° elementInformations
° dynamic_text
> uuid
> orientation
> X
> Y
> data
° terminal
> uuid
> orientation
> X
> Y
> naam
- uuid manufacturer
*uuid element
° names
° elementInformations
° dynamic_text
> uuid
> orientation
> X
> Y
> data
° terminal
> uuid
> orientation
> X
> Y
> naam
galexis wrote:S.DEFFAUX wrote:Je viens de vois les derniers commit de Joshua dans lesquels il supprime plein d'éléments constructeur en "doublon".
Je me sert beaucoup de ces éléments car les info, "constructeur", "référence" ... sont déjà rentré. Suis-je le seul dans ce cas?Perso, je ne pense pas qu'il faille multiplié les symboles identiques juste pour avoir des références différentes. Elle doit rester générique, et la gestion de catalogue constructeur est une autre fonction, qui n'est pas encore développée. Cela doit rester dans la bibliothèque perso.
C'est bête de perdre le travail effectué sur ces symboles, il faudrait conserver certains éléments supprimés par Joshua sur un nouveau dépôt Github, qu'en pensez vous?
Bonjour,
Je suis d'accord. Surtout que je suis contributeur sur de nombreux produits (Legrand & bticino entre autres) qui ne sont pas tous identiques loin de là.
Pour ceux qui souhaitent des références génériques, il y a un dossier pour cela. Mais s'il y a des dossiers par marques/constructeurs je pensais que c'était pour avoir du détail, de la précision.
L'extraction des références des éléments d'un projet me permetait un inventaire détaillé.
Je ne comprends pas cette décision si brutale. A moins que ce ne soit pour gagner très artificiellement du temps de chargement.
Je souhaitais faire de nouvelles propositions. Je vais donc me mettre en stand-by.
Arnaud
@ArnoVal
don't worry yet we work with git, we haven't lost anything
Joshua wants to move forward with it
and scorpio810 (Laurent) brings a compromise
now there is movement, and consultation I am sure a compromise is in the making.
J'ai crée un nouveau dépôt et mis dessus quelques symboles supprimés récemment qui peuvent être utiles.
https://github.com/qelectrotech/qelectr … nt-contribSi vous voyez des symboles qui ont été supprimés mais utiles n’hésitez pas a faire un pull request.
Bonjour Laurent et merci.
Avec Git rien n'est perdu de toute façon (sauf compression de l'historique).
Reste des questions :
* Comment publier (mettre à disposition) ce contrib de façon pratique (tout le monde n'est pas informaticien comme moi) ?
* Comment et qui fait le choix de mettre les éléments dans le repo officiel ou dans le contrib ?
Bizarre cette décision en rc de la version 0.8.
Il eu été intéressant de penser à ce genre de besoin en version 0.9... par un chargeur de composants/de bibliothèques de composants intégré à QElectrotech. Une vrai réflexion sur l'avenir et la praticité du logiciel.
Arnaud
galexis wrote:S.DEFFAUX wrote:Je viens de vois les derniers commit de Joshua dans lesquels il supprime plein d'éléments constructeur en "doublon".
Je me sert beaucoup de ces éléments car les info, "constructeur", "référence" ... sont déjà rentré. Suis-je le seul dans ce cas?Perso, je ne pense pas qu'il faille multiplié les symboles identiques juste pour avoir des références différentes. Elle doit rester générique, et la gestion de catalogue constructeur est une autre fonction, qui n'est pas encore développée. Cela doit rester dans la bibliothèque perso.
C'est bête de perdre le travail effectué sur ces symboles, il faudrait conserver certains éléments supprimés par Joshua sur un nouveau dépôt Github, qu'en pensez vous?
C'est un bon compromis
Bonjour,
j'ai fait le choix d'enlever des éléments pour les mêmes raisons que celles cité par galexis :
Perso, je ne pense pas qu'il faille multiplié les symboles identiques juste pour avoir des références différentes. Elle doit rester générique, et la gestion de catalogue constructeur est une autre fonction, qui n'est pas encore développée. Cela doit rester dans la bibliothèque perso.
Ce qui est le cas pour tous les éléments que j'ai enlever de la collection officiel.
Je ne souhaite blesser personne par ma décision (Qet est un projet libre et communautaire, tous le mondes à sont mot à dire) donc bien que je reste sur l'idée que tous ces éléments sont des doublons uniquement pour avoir des références différente, si la suppression ne fait pas l'unanimité on peu faire un revert des commits en question.
Néanmoins, il faudra à l’avenir voir pour faire différemment, probablement avec la gestion des catalogues constructeur.
Pour résumer mea culpa si la décision ne plais pas, et si vous (les utilisateurs) souhaitez avoir tous ces éléments dans la collection officiel alors on revert (désoler Laurent de te donner du travail inutilement )
joshua, can I have a look to create svg in the element
and further customize the element
to a graphic and a data lib?
I'm not sure what you want (translation english -> french).
You want to know how I want to do this, or you want to start work on this ?
I would therefore remove the elements from the repo
splits the repo into the source code and elements
but this idea still needs some time..
I agree 200%, add a git repos only for the elements and another one for the source code and if it possible (I think it is) make the git repos of element a git submodule of source code git repos.
De-Backer wrote:joshua, can I have a look to create svg in the element
and further customize the element
to a graphic and a data lib?I'm not sure what you want (translation english -> french).
You want to know how I want to do this, or you want to start work on this ?
both, I have not yet decided what the elements should look like and i want to tackle this for QET 0.9
De-Backer wrote:I would therefore remove the elements from the repo
splits the repo into the source code and elements
but this idea still needs some time..I agree 200%, add a git repos only for the elements and another one for the source code and if it possible (I think it is) make the git repos of element a git submodule of source code git repos.
I would go even further, no elements in the source code even with git submodule.
Instead a reference to the repos (libs) that QET can download and store with the user.
then the user can determine what is loaded when QET starts up
i think github, gitlab, and others are perfect for saving element as libs
this will reduce the work for the QET team if there are new elements
we can (but do not have to) refer to the repo's
because the user can also load the repos himself
How it works now:
new elements => download of new QET 0.X
Proposal:
new elements => QET lib download de new elements from the repo
the last commit gives no build warnings for QT5.15.2
yes, 1s for loadeding all Elements
22:48:39.600 Info: "GitRevision 53aaa03967071e2852ca5668f4498071699bcc09"
22:48:39.601 Info: "QElectroTech V 0.80-rc"
22:48:39.601 Info: "Compilatie: GCC 10.2.1 20201117 [revision 98ba03ffe0b9f37b4916ce6238fad754e00d720b]"
22:48:39.601 Info: "Built with Qt 5.15.2 - Date : Dec 4 2020 : 22:47:21"
22:48:39.601 Info: "Run with Qt 5.15.2 using 16 thread(s)"
22:48:39.601 Info: "CPU : model name\t: AMD Ryzen 7 3700X 8-Core Processor\n"
22:48:39.601 Info: "RAM Total : 32026 MB"
22:48:39.601 Info: "RAM Available : 22083 MB"
22:48:39.601 Info: "GPU : "
22:48:39.601 Info: "GPU RAM : @ToDo"
22:48:39.601 Info: "OS : linux - x86_64 - Version : openSUSE Tumbleweed - Kernel : 5.9.11-1-default"
22:48:39.601 Info: *** Qt screens ***
22:48:39.601 Info: "( 1 : 3840 x 2160 )"
22:48:39.859 Info: Elements collection reload
22:48:40.367 Info: Elements collection finished to be loaded
is this a good place for the lib manager?
(/sources/ui/configpage/generalconfigurationpage.cpp)
is this a good place for the lib manager?
Yes this is the good place.
Do not place elements in any Git* repository.
Even KiCAD abandoned Git* plugin as a place for pulling elements from.
Do not place elements in any Git* repository.
Even KiCAD abandoned Git* plugin as a place for pulling elements from.
your text gives no value without sources
furthermore you do not explain why this is a bad idea.
and to close what is your alternative?
I am always willing to listen to reason, if it is substantiated.
Edit:
I would like to hear the reason for your post, so if possible give us an explanation.
Bonjour,
j'ai fait le choix d'enlever des éléments pour les mêmes raisons que celles cité par galexis :galexis wrote:Perso, je ne pense pas qu'il faille multiplié les symboles identiques juste pour avoir des références différentes. Elle doit rester générique, et la gestion de catalogue constructeur est une autre fonction, qui n'est pas encore développée. Cela doit rester dans la bibliothèque perso.
Ce qui est le cas pour tous les éléments que j'ai enlever de la collection officiel.
Je ne souhaite blesser personne par ma décision (Qet est un projet libre et communautaire, tous le mondes à sont mot à dire) donc bien que je reste sur l'idée que tous ces éléments sont des doublons uniquement pour avoir des références différente, si la suppression ne fait pas l'unanimité on peu faire un revert des commits en question.Néanmoins, il faudra à l’avenir voir pour faire différemment, probablement avec la gestion des catalogues constructeur.
Pour résumer mea culpa si la décision ne plais pas, et si vous (les utilisateurs) souhaitez avoir tous ces éléments dans la collection officiel alors on revert (désoler Laurent de te donner du travail inutilement )
Moi ça ma'rrange de lighter la bibliothèque car en readytouse le chargement total est long et la recherche aussi. C'est pour ça qu'il faudrait pouvoir cocher quelle bibliothèque on charge au démarrage....
QElectroTech → News → Nouveautés de la version de développement 0.8
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.037 seconds (44% PHP - 56% DB) with 11 queries