Bug (-: on Linux only, once again ?)

Use this forum to ask questions about how to do things in QCAD.

Moderator: andrew

Forum rules

Always indicate your operating system and QCAD version.

Attach drawing files and screenshots.

Post one question per topic.

User avatar
Husky
Moderator/Drawing Help/Testing
Posts: 4943
Joined: Wed May 11, 2011 9:25 am
Location: USA

Re: Bug (-: on Linux only, once again ?)

Post by Husky » Mon Feb 19, 2024 1:40 am

You can set the global "Label Format" precision like "2 places after point" below:
Menu / Edit / Drawing Preferences / Dimension / Dimension Settings
Work smart, not hard: QCad Pro
Win10/64, QcadPro, QcadCam version: Current.
If a thread is considered as "solved" please change the title of the first post to "[solved] Title..."

SerPat
Active Member
Posts: 25
Joined: Tue Jul 30, 2019 4:52 pm
Location: Chiclayo, pérou

Re: Bug (-: on Linux only, once again ?)

Post by SerPat » Mon Feb 19, 2024 4:13 am

(en)
Thank you very much, Husky.

I had to pass the application in English because I did not find it in the French version (-: it seems that the French word "cotation" is missing in English !). But this only concerns the "dimension settings" in the drawing ("Dimension Tools", WD). Nice try, but I've already tried.

It therefore seems to me that it is a bug: either my system, which I have not modified for months, or QCad which I upgraded at the end of January... I would like to be able to locate the origin, also please tell me if this aberration also appears for you when you open the source or destination document (1st post of this thread), and if you are using the same version as me. I'm convinced this is a QCad bug and I hope it's "triggered" by the contents of one of the sent files.

Tomorrow I install Leap15.5+KDE3 on an SSD, install QCadCam 3.29.3 and inform you of the result…

I did it : no change for QCad.

No one guided me to find the documentation related to
"Edit" menu -> "Application preferences" ->
"Modify": "Explode" : Spline approximation tolerance
“Modify”: “Offset” : Tolerance for clipping
Tolerance for joining segments
“Modify”: “Order connected” : Tolerance
where it is a question of TOLERANCE.

If I insist with this request, it is because I have modified and tried to understand these 1, 2 or 3 items (I no longer remember which one(s), because I ALREADY had precision problems) and this could be where the problem comes from…

NOTE : I still don't know how to erase all traces left by ALL previous QCad installations.

Regards

--------------------------
(fr)
Merci beaucoup, Husky.

J'ai dû passé l'application en anglais car je n'ai pas trouvé dans la version français (-: il semblerait qu'il manque le mot "cotation" en anglais !). Mais cela ne concerne que les "paramètres de cotes" dans le dessin ("Outils de cotes", WD). C'est bien tenté, mais j'avais déjà essayé.

Il me semble donc qu'il s'agit d'un bug : soit mon système, que je n'ai pas modifié depuis des mois, soit QCad que j'ai mis à niveau fin janvier... J'aimerais pouvoir localiser l'origine, aussi dites-moi, sil-vous-plait, si cette aberration apparait également chez vous quand vous ouvrez le document source ou destination (1er post de ce thread), et si vous utilisez la même version que moi. Je suis convaincu que c'est une bug de QCad et j'espère qu'il est "déclenché" par le contenu de l'un des fichiers envoyés.
Demain j'installe Leap15.5+KDE3 sur un SSD, installe QCadCam 3.29.3 et vous informe du résultat…
Je l'ai fait et sans changement pour QCad.
Personne ne m'a guidé pour trouver la documentation relative à
Menu "Édition" -> "Préférences de l'application" ->
"Modifier" : "Décalage"
"Modifier" : "Décomposer"
"Modifier" : "Ordre des objet connectés"
où il est question de tolérance.
Si j'insiste avec cette demande, c'est parce que j'ai modifié et tâcher de compendre ces 1, 2 ou 3 items (je ne me souviens plus le ou lesquels, mais parce que j'avais DÉJÀ des problèmes de précisions) et que ce pourrait être d'ici que viens le problème…

NOTE : je ne sais toujours pas comment effacer toutes traces laissée par TOUTES les installation précédente de QCad.
Attachments
Sélection_001.bmp
Sélection_001.bmp (2.11 MiB) Viewed 979 times

CVH
Premier Member
Posts: 3480
Joined: Wed Sep 27, 2017 4:17 pm

Re: Bug (-: on Linux only, once again ?)

Post by CVH » Mon Feb 19, 2024 6:12 am

The mentioned drawing preferences are about the format for dimension entities.

The number of decimal places displayed as properties are setting for the Property Editor Widget.
See: Application Preferences .. Widgets .. Property Editor .. Decimals/precision
... (Intended are: number of decimal positions, precision is the total amount of significant digits :roll: )
FR: Préférences d'application .. Widgets .. Éditeur de propriétés .. Décimales/précision

Rounding the displayed values of properties does not correct any misalignment in the drawing :!:
On the contrary, it will make you less aware that errors were introduced.

If you expect it to be placed at coordinates with rounded values then there would only be trailing zeros ...
... If not then it is time to inspect why it aren't rounded values.
For that I then prefer maxed out 8 digits. 9 would be better because internally QCAD exploits a point tolerance of 1e-9.

The monstrous error reporteded with Sélection_003.bmp vs Sélection_002.bmp, verifying the entities with those handles.
Related to a coordinate not zero after copy but rather in the nature of -0.0012084
I then assume that the 3 vertical lines in the drawing should be at X= -49 and the other 3 at X= -48
Given that you pointed at the right side near the intersection at (-48,0) at low zoom then the intersection at about Y-47.9988 was the nearest. :wink:
For the entity in question (near x-48) the copy to position (0,0) is then shifted by -0.0012084 ... No surprise there.
DemoOrgSnip1.png
Y=zero, verify the horizontal ruler for X
DemoOrgSnip1.png (3.95 KiB) Viewed 955 times
DemoOrgSnip2.png
Y=zero, verify the horizontal ruler for X
DemoOrgSnip2.png (3.81 KiB) Viewed 955 times

Again, QCAD is much more precise than that, these misalignments are by design.

Regards,
CVH

SerPat
Active Member
Posts: 25
Joined: Tue Jul 30, 2019 4:52 pm
Location: Chiclayo, pérou

Re: Bug (-: on Linux only, once again ?)

Post by SerPat » Mon Feb 19, 2024 11:28 pm

See: Application Preferences .. Widgets .. Property Editor .. Decimals/precision
... (Intended are: number of decimal positions, precision is the total amount of significant digits :roll: )
Everything lights up! I didn't consciously change "Application Preferences .. Widgets .. Property Editor .. Decimals/precision", but I know how I DID NOT do it (!): I often operate the mouse wheel in the dialogs scanned quickly to find out if there is something further down in the window, and if you do it carelessly while the mouse cursor is on an unrolled drop-down menu, you change the item in this menu (Windows Manager: KDE3). It may have happened like that. Then, in front of the displayed values, I noted the errors THAT I HAD NEVER SUPSONED BEFORE! I owe you an apology and offer it to you. And I thought everything was good! I'm still sad.

Unfortunately, I went back to 0 decimal places, then pressed <Enter> in each field, but the nice (-: false) value was not "reset" once enough decimal places were displayed :-(. It's there that there should be a colored display when the "perfect" but rounded display deviates by more than x% from the non-rounded value, and even (let's dream) a sort of "button" to re-enter a value "closer" .

Is there a "trick" to speed up these corrections?


(fr)
See: Application Preferences .. Widgets .. Property Editor .. Decimals/precision
... (Intended are: number of decimal positions, precision is the total amount of significant digits :roll: )
Tout s'éclaire ! Je n'ai pas modifié consciemment «Application Preferences .. Widgets .. Property Editor .. Decimals/precision», mais je sais comment je NE l'ai PAS fait (!) : j'actionne souvent la molette de la souris dans les dialogues parcourus rapidement pour savoir s'il y a quelque chose plus bas dans la fenêtre, or, et si vous le faite négligemment alors que le curseur de la souris est sur un menu déroulant non déroulé, vous changer l'item de ce menu (Windows Manager : KDE3). Cela peut s'être passé comme ça. Ensuite, devant les valeurs affichées, j'ai noté les erreurs QUE JE N'AVAIS JAMAIS SUPSONNÉ AU PARAVANT ! Je vous dois des excuses et vous les présente. Et moi qui croyais que tout était bien ! Je suis tout de même triste.

Malheureusement, je suis retourné à 0 décimale, puis ai pressé <Enter> dans chaque champ, mais la belle (-: fausse) valeur n'a pas été "réinitialisée" une fois suffisamment de décimales affichées :-(. C'est là qu'il faudrait un affichage coloré quand l'affichage "parfait" mais arrondi s'éloigne de plus de x% de la valeur non arrondie, et même (rêvons) une sorte de "bouton" pour ressaisir une valeur au "plus près".

Y aurait-il un "truc" pour accélérer ces corrections ?

CVH
Premier Member
Posts: 3480
Joined: Wed Sep 27, 2017 4:17 pm

Re: Bug (-: on Linux only, once again ?)

Post by CVH » Tue Feb 20, 2024 4:46 am

SerPat wrote:
Mon Feb 19, 2024 11:28 pm
I often operate the mouse wheel in the dialogs scanned quickly to find out if there is something further down in the window, and if you do it carelessly while the mouse cursor is on an unrolled drop-down menu, you change the item in this menu (Windows Manager: KDE3)
A reported issue but I think there is no way around in Qt.
Best practice is to point at the vertical scrollbar when scrolling with the mouse wheel.
SerPat wrote:
Mon Feb 19, 2024 11:28 pm
Unfortunately, I went back to 0 decimal places, then pressed <Enter> in each field, but the nice (-: false) value was not "reset" once enough decimal places were displayed . It's there that there should be a colored display when the "perfect" but rounded display deviates by more than x% from the non-rounded value, and even (let's dream) a sort of "button" to re-enter a value "closer" .

Is there a "trick" to speed up these corrections?
Already addressed in 2019.
https://www.qcad.org/rsforum/viewtopic. ... 293#p24306
When the change per Property Editor is too small it is not preformed at all.
The solution is then a two step approach.
Mainly because the Property Editor only displays rounded values.
Drawing per Property Editor is to be discouraged.

Your propositions for fixing methods are not required when drawings are designed with more care.
What is not wrong does not need to be fixed.
Sometimes it is easier to start from scratch the right way.

And yes, fixing such things will take up some time, you first have to investigate what misalignments there are.
Then reset or redraw them in a certain order.
SerPat wrote:
Mon Feb 19, 2024 11:28 pm
Ensuite, devant les valeurs affichées, j'ai noté les erreurs QUE JE N'AVAIS JAMAIS SUPSONNÉ AU PARAVANT ! Je vous dois des excuses et vous les présente. Et moi qui croyais que tout était bien ! Je suis tout de même triste.
Pas de souci, excuses acceptées, nous sommes là pour vous aider et je suis une personne très patiente.

Regards,
CVH

SerPat
Active Member
Posts: 25
Joined: Tue Jul 30, 2019 4:52 pm
Location: Chiclayo, pérou

Re: Bug (-: on Linux only, once again ?)

Post by SerPat » Tue Feb 20, 2024 6:13 am

(en)
It may be important to note that I am the sole reader and user of the designs I produce. The standards are not necessarily respected (-: and I don't blame myself!). The drawing in the first post of this discussion thread was a draft, a feasibility test in a way, so the precision was not fundamental, but it is still important to be as accurate as possible to easily re-exploit the work.

I have just reworked this draft, with real dimensions. I'm reassured because it's not that heavy or long: the display is done with 8 decimal places and it's ultimately not that painful. Now I should only look at these values to make sure everything is okay. For information, I had difficulty copying from the center of an arc as a reference, even with the SR command (I didn't imagine opening a discussion thread for that!).

Thank you CVH for the bright post. All I'm missing is understanding the app's preferences that deal with various precisions, and I'll mark this thread as resolved.

Should't it be more judicious to place that thread in the forum titled "QCAD Troubleshooting and Problems" ?

Best regards


(fr)
Il peut être important de noter que je suis le seul lecteur et utilisateur des dessins que je produis. Les normes ne sont pas nécessairement respectées (-: et je ne m'en fais pas le reproche !). Le dessin du premier post de ce fil de discussion était un brouillon, un test de faisabilité en quelque sorte, donc la précision n'était pas fondamentale, mais il est tout de même important d'être au plus juste pour facilement ré-exploiter le travail.

Je viens de reprendre ce brouillon, avec des dimensions réelles. Je suis rassuré parce que ce n'est pas si lourd ni long : l'affichage se fait avec 8 décimales et ce n'est finalement pas si pénible. Maintenant, je ne devrais regarder ces valeurs que pour m'assurer que tout va bien. Pour information, j'ai eu des difficultés à copier depuis le centre d'un arc de cercle comme référence, même avec la commande SR (je ne me suis pas imaginé ouvrir un fil de discussion pour ça !).

Merci CVH pour le post lumineux. Il ne me manque plus que la compréhension des préférences de l'application qui traite de divers précisions, et je marquerai ce fil de discussion comme résolu.

Cordialement

CVH
Premier Member
Posts: 3480
Joined: Wed Sep 27, 2017 4:17 pm

Re: Bug (-: on Linux only, once again ?)

Post by CVH » Tue Feb 20, 2024 3:13 pm

Drafting or not, it is always good practice to do it right from the first take. :wink:
SerPat wrote:
Tue Feb 20, 2024 6:13 am
Should't it be more judicious to place that thread in the forum titled "QCAD Troubleshooting and Problems" ?
You can ask one of the moderators to move your topic.
Husky for example, send him a Private Message and elaborate on the reason to do so.
Easiest way of posting a PM is by clicking on his Username (in orange) and take it from there.

Regards,
CVH

CVH
Premier Member
Posts: 3480
Joined: Wed Sep 27, 2017 4:17 pm

Re: Bug (-: on Linux only, once again ?)

Post by CVH » Tue Feb 20, 2024 4:23 pm

SerPat wrote:
Tue Feb 20, 2024 6:13 am
For information, I had difficulty copying from the center of an arc as a reference, even with the SR command (I didn't imagine opening a discussion thread for that!).
Using snap restriction SC would be more appropriated, point to the arc/circle in question not to where the center would be located.
Avoid dualities with other arc/circle or line segments, if required zoom in to ensure that you pick the intended entity.
The entity in question is 'highlighted' what can be darker depending its color.

QCAD will do the rest and use the exact center position as snapping point.
(In full Floating Point notation but only displayed as rounded In the Status Bar)

Regards,
CVH
Last edited by CVH on Wed Feb 21, 2024 5:47 pm, edited 1 time in total.

SerPat
Active Member
Posts: 25
Joined: Tue Jul 30, 2019 4:52 pm
Location: Chiclayo, pérou

Re: Bug (-: on Linux only, once again ?)

Post by SerPat » Wed Feb 21, 2024 4:58 am

Thank you CVH

I remember that I tryed SC to, but yes, i did not succeded probably because an other entity was too near...

Regards

Post Reply

Return to “QCAD 'How Do I' Questions”