176 (edited by galexis 2020-07-01 10:32:51)

Re: Nouveautés de la version de développement 0.8

Bonjour,
avec la readytouse du 30 juin, ni le sommaire, ni la nomenclature ne fonctionnent....
Merci.

Edit : les tableaux semblent vides, mais en faite quand on zoom dessus, il y a bien du texte et à l'impression le résultat est OK. Est-ce que cela vient de mon pc ?

Re: Nouveautés de la version de développement 0.8

Bonjour,

envoie ton projet, ou teste le sur une autre machine?

178 (edited by galexis 2020-07-01 14:50:02)

Re: Nouveautés de la version de développement 0.8

scorpio810 wrote:

Bonjour,

envoie ton projet, ou teste le sur une autre machine?

Je vais tester à la maison.

Post's attachments

Attachment icon Surveillance utilités bâtiment B1 (Château).qet 702.79 kb, 44 downloads since 2020-07-01 

Re: Nouveautés de la version de développement 0.8

Ton projet fonctionne bien sur ma machine.

Re: Nouveautés de la version de développement 0.8

scorpio810 wrote:

- Log -----------------------------------------------------------------
commit ec5f537da433f000ea984dbc7dbabe6a340cb045
Author: Claveau Joshua <Joshua@>
Date:   Thu Jun 18 18:52:29 2020 +0200

    Add new summary table (WIP)

Est-il possible de modifier le format d'affichage de la date dans le sommaire, qui est "année-mois-jou" pour avoir "jour-mois-année" ?
Merci.
Cordialement.

Re: Nouveautés de la version de développement 0.8

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

Re: Nouveautés de la version de développement 0.8

Il me semble que c'est déjà le cas? 
https://git.tuxfamily.org/qet/qet.git/t … e.cpp#n163
@Galexis le format de la date change automatiquement en fonction de la configuration timezone/locale paramétré sur ton PC.

On Windows and Mac, this locale will use the decimal/grouping characters and date/time formats specified in the system configuration panel.

https://doc.qt.io/qt-5/qt.html#DateFormat-enum

Re: Nouveautés de la version de développement 0.8

Joshua wrote:

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

Je suis pas sûr qu'il faille que ce soit en fonction des paramètres PC, mais plutôt projet, car en fonction de la nationalité des clients la demande pourrait être différente....

Re: Nouveautés de la version de développement 0.8

scorpio810 wrote:

Il me semble que c'est déjà le cas? 
https://git.tuxfamily.org/qet/qet.git/t … e.cpp#n163
@Galexis le format de la date change automatiquement en fonction de la configuration timezone/locale paramétré sur ton PC.

On Windows and Mac, this locale will use the decimal/grouping characters and date/time formats specified in the system configuration panel.

https://doc.qt.io/qt-5/qt.html#DateFormat-enum

C'est bien le cas...

Post's attachments

Capture.PNG, 41.31 kb, 488 x 553
Capture.PNG 41.31 kb, 16 downloads since 2020-07-08 

Re: Nouveautés de la version de développement 0.8

Toutes les dates dans QET sont basées sur SystemLocaleShortDate ce qui permet de remplacer automatiquement le format date dans tous tes folios suivant ton client ou en fonction de la configuration PC chez ton client.

https://git.tuxfamily.org/qet/qet.git/l … eShortDate

186 (edited by De-Backer 2020-07-08 16:04:17)

Re: Nouveautés de la version de développement 0.8

scorpio810 wrote:

Toutes les dates dans QET sont basées sur SystemLocaleShortDate ce qui permet de remplacer automatiquement le format date dans tous tes folios suivant ton client ou en fonction de la configuration PC chez ton client.

https://git.tuxfamily.org/qet/qet.git/l … eShortDate

note:
This enum value is deprecated and shall be removed in Qt 6.
https://doc.qt.io/qt-5/qt.html#DateFormat-enum

add info
https://doc.qt.io/qt-5/qlocale.html#FormatType-enum

Re: Nouveautés de la version de développement 0.8

C'est corrigé

Re: Nouveautés de la version de développement 0.8

galexis wrote:

Bonjour,
avec la readytouse du 30 juin, ni le sommaire, ni la nomenclature ne fonctionnent....
Merci.

Edit : les tableaux semblent vides, mais en faite quand on zoom dessus, il y a bien du texte et à l'impression le résultat est OK. Est-ce que cela vient de mon pc ?

Je persiste, il y a un problème d'affichage : la police dans le schéma est pourrie à l'affichage et au PDF c'est pareil.
j'utilise la git6467. Je n'avais pas le problème avec la git6311.

Post's attachments

Capture.PNG, 28.81 kb, 933 x 732
Capture.PNG 28.81 kb, 17 downloads since 2020-07-09 

189 (edited by Naheulf 2020-07-09 21:06:48)

Re: Nouveautés de la version de développement 0.8

Bonjour,
À propos du temps de chargement (particulièrement sous Windows): Ne serait-il pas intéressant de mettre les collections de base (élec, logique, hydro...) dans des fichiers zip (ou autre format de stockage) ? Cela permettrait de diminuer drastiquement le nombre de fichiers à ouvrir sur le disque.
Quant au niveau de compression, le mode "stoker" ou "le plus rapide" me semble approprié pour ce type d'utilisation (chargement le plus rapide possible). Après il faut voir le compromis temps de lecture / temps de décompression. Mais, vu l'énorme taux de compression des fichiers texte (et surtout du XML), y compris en mode "le plus rapide", je pense que ce c'est le niveau de compression qu'il faudra retenir.

Re: Nouveautés de la version de développement 0.8

galexis wrote:

Je persiste, il y a un problème d'affichage : la police dans le schéma est pourrie à l'affichage et au PDF c'est pareil.
j'utilise la git6467. Je n'avais pas le problème avec la git6311.

Merci du retour, j'ai corrigé le "Lancer QET.bat" de mon coté pour les prochaines ReadyToUse.
Comme il y a un souci avec le commit : "Fix wrong date format for nomenclature table" te faudra attendre que ce soit résolu.

En entendant modifie dans ton .bat la commande en:

set command=bin\qelectrotech.exe -platform windows:fontengine=freetype --common-elements-dir=elements/ --common-tbt-dir=titleblocks/ --lang-dir=lang/ %*

https://git.tuxfamily.org/qet/qet.git/c … 9e09f132c3

Re: Nouveautés de la version de développement 0.8

scorpio810 wrote:
galexis wrote:

Je persiste, il y a un problème d'affichage : la police dans le schéma est pourrie à l'affichage et au PDF c'est pareil.
j'utilise la git6467. Je n'avais pas le problème avec la git6311.

Merci du retour, j'ai corrigé le "Lancer QET.bat" de mon coté pour les prochaines ReadyToUse.
Comme il y a un souci avec le commit : "Fix wrong date format for nomenclature table" te faudra attendre que ce soit résolu.

En entendant modifie dans ton .bat la commande en:

set command=bin\qelectrotech.exe -platform windows:fontengine=freetype --common-elements-dir=elements/ --common-tbt-dir=titleblocks/ --lang-dir=lang/ %*

https://git.tuxfamily.org/qet/qet.git/c … 9e09f132c3

Ok merci. Ca fonctionne.

Re: Nouveautés de la version de développement 0.8

I met with some kind of bug on the contacts. If the contact is subordinated to the coil, then everything is fine, and if subordinated any switch or fuse, the link to the switch comes over to the text of the switch room. I tried to create a new switch with the button properties, but the problem still remains.
[img]kontact.png[/img]

Post's attachments

kontact.png, 26.48 kb, 590 x 298
kontact.png 26.48 kb, 16 downloads since 2020-07-10 

Re: Nouveautés de la version de développement 0.8

@Alexander:
change to
https://download.tuxfamily.org/qet/forum_img_2/alexander_xref.png

Re: Nouveautés de la version de développement 0.8

Thanks for the help. But the problem is strange. On the contacts from the coils when installed "bottom" shows the bottom. And on the contacts associated with the switches, the link remains on top. After the project is closed, these settings are not saved. I did not understand why it was necessary to share connected contacts with different objects. In practice, I have never seen such a separation. Even in pneumatics.

Post's attachments

kontact2.png, 57.97 kb, 982 x 564
kontact2.png 57.97 kb, 22 downloads since 2020-07-10 

Re: Nouveautés de la version de développement 0.8

I saw the same issue on many config, change it in on general settings and also on your project.

Re: Nouveautés de la version de développement 0.8

De-Backer wrote:
scorpio810 wrote:

Toutes les dates dans QET sont basées sur SystemLocaleShortDate ce qui permet de remplacer automatiquement le format date dans tous tes folios suivant ton client ou en fonction de la configuration PC chez ton client.

https://git.tuxfamily.org/qet/qet.git/l … eShortDate

note:
This enum value is deprecated and shall be removed in Qt 6.
https://doc.qt.io/qt-5/qt.html#DateFormat-enum

add info
https://doc.qt.io/qt-5/qlocale.html#FormatType-enum

WIP :

Post's attachments

Attachment icon 0001-WIP-Fix-Qt-SystemLocaleShortDate-this-enum-value-is-.patch 2.35 kb, 19 downloads since 2020-07-12 

Attachment icon 0001-WIP3-Fix-Qt-SystemLocaleShortDate-this-enum-value-is.patch 1.18 kb, 18 downloads since 2020-07-12 

Re: Nouveautés de la version de développement 0.8

Naheulf wrote:

Bonjour,
À propos du temps de chargement (particulièrement sous Windows): Ne serait-il pas intéressant de mettre les collections de base (élec, logique, hydro...) dans des fichiers zip (ou autre format de stockage) ? Cela permettrait de diminuer drastiquement le nombre de fichiers à ouvrir sur le disque.
Quant au niveau de compression, le mode "stoker" ou "le plus rapide" me semble approprié pour ce type d'utilisation (chargement le plus rapide possible). Après il faut voir le compromis temps de lecture / temps de décompression. Mais, vu l'énorme taux de compression des fichiers texte (et surtout du XML), y compris en mode "le plus rapide", je pense que ce c'est le niveau de compression qu'il faudra retenir.

Bonjour,

Il n'y a que sous MS Windows que le chargement est très long, par exemple sur une machine Linux le chargement des 7000 éléments c'est de l'ordre de quelques secondes. Sur la 0.8-dev nous avons amélioré sensiblement les temps de chargement:
https://qelectrotech.org/forum/viewtopi … 995#p10995
https://github.com/Microsoft/WSL/issues … -425272829

SvenGroot commented on 28 Sep 2018 •
edited
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.

https://programmer.group/efficiency-com … idxml.html

Let's take a look at the results under windows:
https://download.tuxfamily.org/qet/forum_img_2/77f9ab39b41c2da49429bd9a42793f77.jpg
My reaction was WTF?? Why does the same function read the same file ten times have such a big difference, so I will add delay when the file opens and closes, hoping to avoid the impact of the process of file switch on this function, the result still has not solved this problem, I hope God can help me solve this problem!

Now let's look at the results of linux:
https://download.tuxfamily.org/qet/forum_img_2/7aa8c336570e152ed7708e15ee6929e4.jpg
Obviously, the time under linux is relatively stable and credible, so we only need to use the time under linux as a reference for later testing.


Tu as essayé avec WSL2?
https://docs.microsoft.com/fr-fr/windows/wsl/wsl2-index

Re: Nouveautés de la version de développement 0.8

- Log -----------------------------------------------------------------
commit 132f3ad1b41f803a6ca9a78fdc9480196277a5d5
Author: Claveau Joshua <Joshua@>
Date:   Tue Jul 14 20:00:28 2020 +0200

    Remove old summary feature

Re: Nouveautés de la version de développement 0.8

Aleksandr wrote:

Thanks for the help. But the problem is strange. On the contacts from the coils when installed "bottom" shows the bottom. And on the contacts associated with the switches, the link remains on top. After the project is closed, these settings are not saved. I did not understand why it was necessary to share connected contacts with different objects. In practice, I have never seen such a separation. Even in pneumatics.

Maybe since this commit? :
https://git.tuxfamily.org/qet/qet.git/c … d990aabff5

Re: Nouveautés de la version de développement 0.8

- Log -----------------------------------------------------------------
commit ac49ecce7d5d731cb39ac0ad89f67837847fe319
Author: Claveau Joshua <Joshua@>
Date:   Wed Jul 15 20:48:52 2020 +0200

    Fix wrong position of slave xref after open a saved project