the current is on the server, maybe I should go look for it on the backup machines ..
I'm watching this last week.
3,526 2020-01-18 20:15:31
Re: AppImages (13 replies, posted in News)
3,527 2020-01-18 20:13:56
Re: Type Field in Terminal Block Generator (4 replies, posted in Terminal block generator)
Hi Matt, see
https://www.cnet.com/how-to/five-ways-t … -trackpad/
3,528 2020-01-18 15:22:45
Re: DXFtoQET V3.0 vertical text changed after converting (1 replies, posted in Import DXF)
Hi,
a workaround is to edit with a good text editor the XML or your element.elmt file and change orientation text value.
<text y="-193.869" font="Sans Serif,6,-1,5,50,0,0,0,0,0" text=" X1:12" x="230.632" rotation="0" color="#000000"/>
<text y="-74.9248" font="Sans Serif,6,-1,5,50,0,0,0,0,0" text=" X1:15" x="230.632" rotation="0" color="#000000"/>
<text y="-94.7488" font="Sans Serif,6,-1,5,50,0,0,0,0,0" text=" X1:14" x="230.632" rotation="0" color="#000000"/>
<text y="-15.4528" font="Sans Serif,6,-1,5,50,0,0,0,0,0" text=" X1:16" x="230.632" rotation="0" color="#000000"/><dynamic_text z="5" x="-35" y="-25" rotation="90" uuid="{9fc2bc91-3b9b-431f-8bbc-72050c94cacd}" Halignment="AlignLeft" font="rsfs10,9,-1,5,50,1,0,0,0,0,LyX" text_width="-1" frame="false" Valignment="AlignTop" text_from="UserText">
3,529 2020-01-18 15:16:03
Re: Element Editor Question (4 replies, posted in EN : Help, suggestions, discussions, ...)
Yes function " do not rotate element texts when element is rotated" existed before, but deleted since so complicate useless the code with dynamic texts.. and no one was using this function ...
3,530 2020-01-18 10:32:40
Re: Financement nouvelle machine de build (23 replies, posted in News)
I hope you like new features added since. 
3,531 2020-01-17 22:59:48
Re: AppImages (13 replies, posted in News)
On AppImage machine builder:
laurent@debian:~$ dpkg -l |grep ii | grep xcb
ii libx11-xcb-dev:amd64 2:1.6.4-3+deb9u1 amd64 Xlib/XCB interface library (development headers)
ii libx11-xcb1:amd64 2:1.6.4-3+deb9u1 amd64 Xlib/XCB interface library
ii libxcb-composite0:amd64 1.12-1 amd64 X C Binding, composite extension
ii libxcb-cursor0:amd64 0.1.1-3 amd64 utility libraries for X C Binding -- cursor
ii libxcb-damage0:amd64 1.12-1 amd64 X C Binding, damage extension
ii libxcb-dpms0:amd64 1.12-1 amd64 X C Binding, dpms extension
ii libxcb-dri2-0:amd64 1.12-1 amd64 X C Binding, dri2 extension
ii libxcb-dri2-0-dev:amd64 1.12-1 amd64 X C Binding, dri2 extension, development files
ii libxcb-dri3-0:amd64 1.12-1 amd64 X C Binding, dri3 extension
ii libxcb-dri3-dev:amd64 1.12-1 amd64 X C Binding, dri3 extension, development files
ii libxcb-glx0:amd64 1.12-1 amd64 X C Binding, glx extension
ii libxcb-glx0-dev:amd64 1.12-1 amd64 X C Binding, glx extension, development files
ii libxcb-icccm4:amd64 0.4.1-1 amd64 utility libraries for X C Binding -- icccm
ii libxcb-image0:amd64 0.4.0-1+b2 amd64 utility libraries for X C Binding -- image
ii libxcb-keysyms1:amd64 0.4.0-1+b2 amd64 utility libraries for X C Binding -- keysyms
ii libxcb-present-dev:amd64 1.12-1 amd64 X C Binding, present extension, development files
ii libxcb-present0:amd64 1.12-1 amd64 X C Binding, present extension
ii libxcb-randr0:amd64 1.12-1 amd64 X C Binding, randr extension
ii libxcb-randr0-dev:amd64 1.12-1 amd64 X C Binding, randr extension, development files
ii libxcb-record0:amd64 1.12-1 amd64 X C Binding, record extension
ii libxcb-render-util0:amd64 0.3.9-1 amd64 utility libraries for X C Binding -- render-util
ii libxcb-render0:amd64 1.12-1 amd64 X C Binding, render extension
ii libxcb-render0-dev:amd64 1.12-1 amd64 X C Binding, render extension, development files
ii libxcb-shape0:amd64 1.12-1 amd64 X C Binding, shape extension
ii libxcb-shape0-dev:amd64 1.12-1 amd64 X C Binding, shape extension, development files
ii libxcb-shm0:amd64 1.12-1 amd64 X C Binding, shm extension
ii libxcb-sync-dev:amd64 1.12-1 amd64 X C Binding, sync extension, development files
ii libxcb-sync1:amd64 1.12-1 amd64 X C Binding, sync extension
ii libxcb-util0:amd64 0.3.8-3+b2 amd64 utility libraries for X C Binding -- atom, aux and event
ii libxcb-xfixes0:amd64 1.12-1 amd64 X C Binding, xfixes extension
ii libxcb-xfixes0-dev:amd64 1.12-1 amd64 X C Binding, xfixes extension, development files
ii libxcb-xinerama0:amd64 1.12-1 amd64 X C Binding, xinerama extension
ii libxcb-xkb1:amd64 1.12-1 amd64 X C Binding, XKEYBOARD extension
ii libxcb-xv0:amd64 1.12-1 amd64 X C Binding, xv extension
ii libxcb1:amd64 1.12-1 amd64 X C Binding
ii libxcb1-dev:amd64 1.12-1 amd64 X C Binding, development files
laurent@debian:~$
3,532 2020-01-17 20:02:46
Re: Financement nouvelle machine de build (23 replies, posted in News)
Thanks Morgan.
3,533 2020-01-17 19:58:49
Re: AppImages (13 replies, posted in News)
Filter on xcb package installed here :
~$ dpkg -l |grep ii | grep xcb
ii libx11-xcb-dev:amd64 2:1.6.8-1 amd64 Xlib/XCB interface library (development headers)
ii libx11-xcb1:amd64 2:1.6.8-1 amd64 Xlib/XCB interface library
ii libxcb-composite0:amd64 1.13.1-3 amd64 X C Binding, composite extension
ii libxcb-cursor0:amd64 0.1.1-4 amd64 utility libraries for X C Binding -- cursor
ii libxcb-damage0:amd64 1.13.1-3 amd64 X C Binding, damage extension
ii libxcb-dpms0:amd64 1.13.1-3 amd64 X C Binding, dpms extension
ii libxcb-dri2-0:amd64 1.13.1-3 amd64 X C Binding, dri2 extension
ii libxcb-dri2-0-dev:amd64 1.13.1-3 amd64 X C Binding, dri2 extension, development files
ii libxcb-dri3-0:amd64 1.13.1-3 amd64 X C Binding, dri3 extension
ii libxcb-dri3-dev:amd64 1.13.1-3 amd64 X C Binding, dri3 extension, development files
ii libxcb-glx0:amd64 1.13.1-3 amd64 X C Binding, glx extension
ii libxcb-glx0-dev:amd64 1.13.1-3 amd64 X C Binding, glx extension, development files
ii libxcb-icccm4:amd64 0.4.1-1.1 amd64 utility libraries for X C Binding -- icccm
ii libxcb-image0:amd64 0.4.0-1+b2 amd64 utility libraries for X C Binding -- image
ii libxcb-keysyms1:amd64 0.4.0-1+b2 amd64 utility libraries for X C Binding -- keysyms
ii libxcb-present-dev:amd64 1.13.1-3 amd64 X C Binding, present extension, development files
ii libxcb-present0:amd64 1.13.1-3 amd64 X C Binding, present extension
ii libxcb-randr0:amd64 1.13.1-3 amd64 X C Binding, randr extension
ii libxcb-randr0-dev:amd64 1.13.1-3 amd64 X C Binding, randr extension, development files
ii libxcb-record0:amd64 1.13.1-3 amd64 X C Binding, record extension
ii libxcb-render-util0:amd64 0.3.9-1+b1 amd64 utility libraries for X C Binding -- render-util
ii libxcb-render0:amd64 1.13.1-3 amd64 X C Binding, render extension
ii libxcb-render0-dev:amd64 1.13.1-3 amd64 X C Binding, render extension, development files
ii libxcb-res0:amd64 1.13.1-3 amd64 X C Binding, res extension
ii libxcb-shape0:amd64 1.13.1-3 amd64 X C Binding, shape extension
ii libxcb-shape0-dev:amd64 1.13.1-3 amd64 X C Binding, shape extension, development files
ii libxcb-shm0:amd64 1.13.1-3 amd64 X C Binding, shm extension
ii libxcb-shm0-dev:amd64 1.13.1-3 amd64 X C Binding, shm extension, development files
ii libxcb-sync-dev:amd64 1.13.1-3 amd64 X C Binding, sync extension, development files
ii libxcb-sync1:amd64 1.13.1-3 amd64 X C Binding, sync extension
ii libxcb-util0:amd64 0.3.8-3+b2 amd64 utility libraries for X C Binding -- atom, aux and event
ii libxcb-xfixes0:amd64 1.13.1-3 amd64 X C Binding, xfixes extension
ii libxcb-xfixes0-dev:amd64 1.13.1-3 amd64 X C Binding, xfixes extension, development files
ii libxcb-xinerama0:amd64 1.13.1-3 amd64 X C Binding, xinerama extension
ii libxcb-xinput0:amd64 1.13.1-3 amd64 X C Binding, xinput extension
ii libxcb-xkb1:amd64 1.13.1-3 amd64 X C Binding, XKEYBOARD extension
ii libxcb-xv0:amd64 1.13.1-3 amd64 X C Binding, xv extension
ii libxcb1:amd64 1.13.1-3 amd64 X C Binding
ii libxcb1-dev:amd64 1.13.1-3 amd64 X C Binding, development files~$ aptitude search ~i | grep xcb
i libx11-xcb-dev - Xlib/XCB interface library (development headers)
i A libx11-xcb1 - Xlib/XCB interface library
i libxcb-composite0 - X C Binding, composite extension
i A libxcb-cursor0 - utility libraries for X C Binding -- cursor
i libxcb-damage0 - X C Binding, damage extension
i libxcb-dpms0 - X C Binding, dpms extension
i libxcb-dri2-0 - X C Binding, dri2 extension
i libxcb-dri2-0-dev - X C Binding, dri2 extension, development files
i libxcb-dri3-0 - X C Binding, dri3 extension
idA libxcb-dri3-dev - X C Binding, dri3 extension, development files
i libxcb-glx0 - X C Binding, glx extension
i libxcb-glx0-dev - X C Binding, glx extension, development files
i libxcb-icccm4 - utility libraries for X C Binding -- icccm
i A libxcb-image0 - utility libraries for X C Binding -- image
i A libxcb-keysyms1 - utility libraries for X C Binding -- keysyms
i libxcb-present-dev - X C Binding, present extension, development files
i A libxcb-present0 - X C Binding, present extension
i libxcb-randr0 - X C Binding, randr extension
i libxcb-randr0-dev - X C Binding, randr extension, development files
id libxcb-record0 - X C Binding, record extension
i libxcb-render-util0 - utility libraries for X C Binding -- render-util
i libxcb-render0 - X C Binding, render extension
i A libxcb-render0-dev - X C Binding, render extension, development files
i A libxcb-res0 - X C Binding, res extension
i libxcb-shape0 - X C Binding, shape extension
i A libxcb-shape0-dev - X C Binding, shape extension, development files
i libxcb-shm0 - X C Binding, shm extension
i A libxcb-shm0-dev - X C Binding, shm extension, development files
i libxcb-sync-dev - X C Binding, sync extension, development files
i A libxcb-sync1 - X C Binding, sync extension
i A libxcb-util0 - utility libraries for X C Binding -- atom, aux and event
i libxcb-xfixes0 - X C Binding, xfixes extension
i A libxcb-xfixes0-dev - X C Binding, xfixes extension, development files
i libxcb-xinerama0 - X C Binding, xinerama extension
i A libxcb-xinput0 - X C Binding, xinput extension
i libxcb-xkb1 - X C Binding, XKEYBOARD extension
i libxcb-xv0 - X C Binding, xv extension
i libxcb1 - X C Binding
i A libxcb1-dev - X C Binding, development files
3,534 2020-01-17 17:42:27
Re: AppImages (13 replies, posted in News)
Hi,
$ ./QElectroTech_0.8-DEV-r6112-x86_64.AppImage
$
works nicely here, strange.
Maybe a kde bug ?
https://bugs.launchpad.net/ubuntu/+sour … bug/782779
https://bbs.archlinux.org/viewtopic.php?id=252115
3,535 2020-01-17 15:47:38
Re: Element Editor Question (4 replies, posted in EN : Help, suggestions, discussions, ...)
Hi,
not in editor, but element is easy to rotate on your folios whit key space.
3,536 2020-01-16 19:33:41
Re: Modifier toutes les polices (7 replies, posted in FR : Aide, suggestions, discussions, ...)
- la police du cartouche (intégré au projet) ne change pas
Cherche pas ça n'a pas encore été ajouté.
3,537 2020-01-16 13:13:32
Re: Épaisseur de la ligne finr (6 replies, posted in FR : Aide, suggestions, discussions, ...)
J'ai jamais eu ce soucis avec des imprimantes laser HP depuis Linux, c'est quoi ton imprimante?
3,538 2020-01-15 14:49:12
Re: Dons (13 replies, posted in Bar Fourre-tout)
Domain name renewed €18,79 EUR .
3,539 2020-01-14 21:21:01
Re: Modifier toutes les polices (7 replies, posted in FR : Aide, suggestions, discussions, ...)
Fait attention les polices sont ecrites sous la forme :
independent_text_font="Sans Serif,9,-1,5,50,0,0,0,0,0,Condensed"
dynamic_text_font="Liberation Sans Narrow,9,-1,5,75,0,0,0,0,0,Bold"
independent_text_font="Liberation Sans,9,-1,5,75,0,0,0,0,0,Bold"
3,540 2020-01-14 06:35:26
Re: Financement nouvelle machine de build (23 replies, posted in News)
Clair, ça monte vite, mais on peut dire merci à AMD car coté Intel c'etais plutôt de l'ordre de 20 000$ le CPU..
3,541 2020-01-13 21:14:45
Re: just updated to 0.7: can't edit labels anymore (3 replies, posted in EN : Help, suggestions, discussions, ...)
No, is very old.
3,542 2020-01-13 10:54:46
Re: Épaisseur de la ligne finr (6 replies, posted in FR : Aide, suggestions, discussions, ...)
Bonjour,
je ne sais pas quelle version tu utilises, mais c'est disponible depuis la 0.7 pour les conducteurs et les basic shapes.
3,543 2020-01-13 10:48:18
Re: Financement nouvelle machine de build (23 replies, posted in News)
Bonjour,
j'ai fait quelques simulations :
Ryzen 9 3950X : Nb de cœurs du CPU 16 Nb de threads 32 Fréquence de base 3.5GHz Total cache L3 64MB
Threadripper 3960X : Nb de cœurs du CPU 24 Nb de threads 48 Fréquence de base 3.8GHz Total cache L3 128MB
Pour le 3950X ça passe sans problème, pour le 3960X qui serait plus pérenne sur le long terme, si je rajoute à la cagnotte les 320€ du compte Paypal il en manquerai encore un peu, trop pour que je puisse compléter de ma poche, sans que madame hurle...., huhu.
Mais je me connais, plus il y aura de puissance sous le capot plus je vais pourvoir explorer d'autres cross-compilateur, continuer les essais Qt webassembly même si la techno est encore jeune mais très prometteuse, et autres joujoux .. et nouvelles features dont vous êtes friand
Pour Qt webassembly je l'ai un peu mis de coté pour l'instant, j'y ai passé une semaine a compiler sans relâche entre les fêtes de fin d'année les sources Qt 5.13.2, 5.14, etc, avec différentes version du toolchain emscripten mais j'ai toujours des erreurs de compilation si j'active WASM_OBJECT_FILES=1 .
Ça devrait intéresser certains de nos users comme les PME-PMI, Lycées, ou ceux qui veulent utiliser QET depuis un navigateur Web sur leur tablettes Ipad ou Android sur le terrain.
Le temps gagné sur le long terme devrait être intéressant avec le 3960X au lieu de compiler en make -j32 compiler en make -j48.
J'aimerai avoir vos avis, que feriez vous a ma place, prendre le 3950X maintenant ou attendre pour le 3960X?
Dans les deux cas la puissance sera doublée ou triplée.
Encore merci à tous pour vos soutiens.
3,544 2020-01-12 00:43:57
Re: Modifier toutes les polices (7 replies, posted in FR : Aide, suggestions, discussions, ...)
Si tu veux vraiment changer, un moyen simple est d'ouvrir le fichier de ton projet avec un bon éditeur texte et remplacer les polices dans la définition des éléments dans le XML.
Fait un backup de ton projet avant.
3,545 2020-01-12 00:05:14
Re: Modifier toutes les polices (7 replies, posted in FR : Aide, suggestions, discussions, ...)
Bonsoir,
change les polices et relances ton projet.
Si je me souvient bien, j'avais fait quelques tests pour changer aussi directement les polices des éléments déjà posés sur les folios mais .... c'étais il me semble un peu dangereux pour vos projets donc j'avais pas continué et envoyé le patch.
3,546 2020-01-11 23:17:56
Re: Nouveautés de la version de développement 0.8 (317 replies, posted in News)
Non, la collection n'est pas protégée avec la ReadyToUse sinon le .bat n’aurait pas besoin de le faire, mais c'est clair que de le faire a chaque lancement c'est du temps perdu.
Quant a réduire la collection, non ! et c'est ce qui fait la richesse de QET ;-) , certes on a comme dit plus haut un petit nombre d’élément en doublons qui faudrait surement trier.. Sinon avec l'installeur vous avez le choix d'installer ou pas les dossiers éléments dont vous avez besoin, et ne pas cliquer comme un sauvage sur suivant, suivant, suivant, etc ... 
sur la ReadyToUse c'est tres facile de supprimer ou déplacer ailleurs sur vos disques les dossiers éléments de la collection officielle dont vous vous servirez jamais si vous voulez gagner du temps. Pareillement avec l'installeur suffit d'aller dans program\QElectroTech\elements\
En fait même sous Windows les temps de lancement se sont bien réduits, le travail a porté ses fruits, ok ça ce lancera jamais en un éclair comme une bonne machine Linux et un bon SSD ...
Réponse éclairée d'un dev Windows, Cf lien plus haut:
I wish this problem was as easy as saying "NTFS is slow" or "DrvFs is slow". We've long since gotten all the low-hanging fruit and are left with what is essentially "death by a thousand cuts," with no single component responsible for our (lack of) performance, but with lots of different things contributing.
The IO subsystem is architected very differently in Windows than it is in Linux, with different goals in mind. Some of the major differences we have to deal with are:
Linux has a top-level directory entry cache that means that certain queries (most notably stat calls) can be serviced without calling into the file system at all once an item is in the cache. Windows has no such cache, and leaves much more up to the file systems. A Win32 path like C:\dir\file gets translated to an NT path like \??\C:\dir\file, where \??\C: is a symlink in Object Manager to a device object like \Device\HarddiskVolume4. Once such a device object is encountered, the entire remainder of the path is just passed to the file system, which is very different to the centralized path parsing that VFS does in Linux.
Windows's IO stack is extensible, allowing filter drivers to attach to volumes and intercept IO requests before the file system sees them. This is used for numerous things, including virus scanning, compression, encryption, file virtualization, things like OneDrive's files on demand feature, gathering pre-fetching data to speed up app startup, and much more. Even a clean install of Windows will have a number of filters present, particularly on the system volume (so if you have a D: drive or partition, I recommend using that instead, since it likely has fewer filters attached). Filters are involved in many IO operations, most notably creating/opening files.
The NT file system API is designed around handles, not paths. Almost any operation requires opening the file first, which can be expensive. Even things that on the Win32 level seem to be a single call (e.g. DeleteFile) actually open and close the file under the hood. One of our biggest performance optimizations for DrvFs which we did several releases ago was the introduction of a new API that allows us to query file information without having to open it first.
Whether we like it or not (and we don't), file operations in Windows are more expensive than in Linux, even more so for those operations that only touch file metadata (such as stat). The costs of these operations are spread all over the place, from Object Manager and IO manager, to the filters, and NTFS. If it was as simple as saying "NTFS is slow," we'd simply spend a release optimizing NTFS (and we have spent time doing just that), but our costs are so spread out over many components that there just isn't a silver bullet anymore. And we can only ever address in-box filters; who knows what third party filters are doing. We do work with the vendors of those filters to try and improve things. For example, when we introduced the new API to query file information without opening it, we needed filter drivers to support that. We needed to make sure we didn't break the system if some installed filters didn't support it (basically by falling back to a open/query/close operation). Making sure everybody supported this so you, our users, got the maximum speed benefit from that change took a lot of time and effort. The same thing is true for something like the case-sensitive directory work; we had to make sure our filter ecosystem could handle this new behavior.When Rich was talking about app behavior above, he wasn't trying to blame the apps for behaving that way. These apps were written on a system where file system operations are incredibly fast, and we're trying to run them, unmodified (unlike e.g. Git for Windows which tries to optimize its access patterns to better fit the Windows way of doing things) on a system that, unfortunately, is not as fast.
And it's not even as simple as saying "Windows is the cause of the slowness" either, since WSL does play a role. Most notably, Windows path parsing is very different than Linux path parsing (and, as I said above, is the responsibility of the file system, so can differ between file systems, while on Linux it's centralized). Linux apps expect the Linux behavior, so we have to carefully emulate that behavior, and unfortunately that means sending more operations down to the file system. Something like a stat call, which in Linux can be served entirely from the kernel's own cache if you're lucky, for WSL requires sending multiple file system requests, all of which have to traverse the entire filter stack. We've done a lot of work, even as recent as the upcoming 1809, to reduce the amount of extra work WSL has to do. But the differences between Linux and Windows's API mean there'll always be some extra work, at least.
Basically, this isn't a simple problem, and everything we do involves multiple components, and often involves working with Microsoft's partners if the changes affect filter drivers.
That doesn't mean we've given up either. We're still making changes, and are actively exploring new avenues to make WSL faster, and thus more useful, for you. Of course, I wish I could tell you exactly what we're doing and what our timeline is, but that's unfortunately not the corporate reality we live in.
@Galexis : t'as pas essayé de créer un RAMDISK , ça pourrait te faire gagner un peu de temps?
3,547 2020-01-11 10:01:31
Re: Nouveautés de la version de développement 0.8 (317 replies, posted in News)
Parser les XML des ~ 6183 elements dans 846 categories (soit 7029 fichiers) est très coûteux en I/O et en temps machine sous Windows, il est plus rapide de tout copier en RAM et les analyser ensuite. Vous comprenez pourquoi la progressBar ne commence qu’après quelques secondes sous Windows.
Je pense qu'on peut aussi gratter encore une ou deux secondes sous Windows avec la version ReadyToUse, forcer les attributs de la collection officielle en lecture seule dans le package plutôt que de le faire à chaque lancement de QET par le fichier.bat, comme les packages Linux. Du style QMAKE_COPY_DIR = xcopy /s /q /y /i /r
Il est clair que certains le font déjà sur leur ReadyToUse pour gratter quelque secondes à chaque lancement de QET, forcer le dossier élément en readonly et supprimer la ligne dans le .bat.
rem Met la collection QET en lecture seule
attrib +r elements/* /S /D
3,548 2020-01-10 18:20:37
Re: Suggestions pour les images (1 replies, posted in FR : Aide, suggestions, discussions, ...)
Bonjour,
oui on a y a pensé, mais ce ne sera pas pour tout de suite d'avoir un fichier projet sous forme de container fichier XML + dossier image archive.
3,549 2020-01-10 18:18:54
Re: Discussion sur la liste des fileries (25 replies, posted in FR : Aide, suggestions, discussions, ...)
3,550 2020-01-10 18:17:18
Re: just updated to 0.7: can't edit labels anymore (3 replies, posted in EN : Help, suggestions, discussions, ...)
Your element is a slave element. Slave element take the matser label name automaticly when you link master like coil to slave contacts!
Put a coil in your diagram, in information widget edit label, now link your new master coil to your element power contacts slave by selecting with right click and link.