Center of circle relative to edge.

Discussions about the development of the TechDraw workbench
domad
Posts: 196
Joined: Mon Jun 22, 2020 12:16 pm

Re: Center of circle relative to edge.

Postby domad » Fri Aug 28, 2020 3:37 pm

aapo wrote:
Fri Aug 28, 2020 11:43 am
domad wrote:
Fri Aug 28, 2020 10:24 am
I invite you to reflect on Linus Torvalds' thought, this is what it says:

- It's not that i refrain from taking sides. It's just that i deeply blame anyone who tries to impose their morals on others. And you can replace the word "moral" with religion, computer faith, or more.
- As a technician, i know that technology doesn't transform a damn thing. Society is changing technology, not the other way around. Technology only sets the limits of what we can do and how much it costs us to do it.


These are words to be framed don't you think?
I certainly agree with that. Linus is not afraid to say how it is. :D

Having said that i tell you that your speech is off topic since you too do not express your thoughts on what the topic is: the "snaps" extended to any workbench including TechDraw would be a positive or negative fact for FreeCad (?), also explaining reasons.
Well, I did say that the idea of "snapping" would be a good one in theory. And, I also believe that a possibility of "snapping" the dimensions would probably have solved the problem in the topic of the original post; namely first by the creation of a "floating" dimension, and then "snapping" the ends to the desired geometry points. It is a good idea, but the whole idea is unfortunately off-topic in this thread, because the functionality is yet to be programmed, and in this thread the discussion was about finding immediate solution to the problem of creating a dimension with the current version of FreeCAD TechDraw. Fortunately, the problem was that using multiselection was not intuitive for a new user, so it could be solved without any new code. Probably, this problem would be best solved with UI hints or documentation improvements, at least for the immediate future. With your suggestion, there would be no definite requirement of using multiselection (if I understood the idea correctly); but someone would first need to code it. It's the harsh reality.

I know very well (!) That the developers (maybe you are too) of FreeCad, LibreOffice, Gimp, Inkscape, LibreCad, Blender, Meshlab, etc. are enthusiasts who program by sacrificing their free time:
- so remember and never forget it (!), even we, professionals, use our "free" time dedicating it to FreeCad (i assure you that it is not for "playing"!) and thus contributing to its development.
No, I'm just a fellow user and not a developer, at least for now. Although, I'm also a hobbyist programmer, that's why I suggested the same path for you. I also dedicate some "free" time for bug reports and testing in FreeCAD, and I sometimes also read the code. Thus, I fully agree with your idea of contributing to its development by means other than coding, because I try to do the same. :)

However, the harsh reality in the open-source world is that if you don't code, your ideas may or may not be forgotten depending on whether any of the developers are personally interested on them. There might be goals or roadmaps, but everyone is free to develop the things they are personally most interested in.

I hope my English was decent…. good day
In my opinion, perfectly understandable English. Although, English is not my native tongue either, so who am I to judge. Good day to you, too. :D
“aapo” thanks for your reply.
Very well I see that we are on the same line, what I regret is that you intervened to defend the work of the developers or moderators at all costs even when they say nonsense:
"Chrisb" said: “For what do you need the technical drawings? They may still be common for communication with a shop where you get your part machined…..” if that were the case it would make no sense what commercial parallels continue to develop for technical drawing: Medusa4, Tekla, Autocad, Invetor, Catia, SolidWorks, solid edge and many others.
He also criticized an example non-standard design: “….but let me tell you, they will not be happy if you give them drawings showing a hole with an arc length of 6.28mm for a quarter arc which should have a distance from its border to the borders of the model of 6mm….. They probably expect and sure will be faster if you tell them to drill a 8mm hole at a distance of 10mm to the borders” not remembering that we are not lecturing on how to dimension a drawing according to standard (i am a professional in the sector, I certainly cannot accept such criticisms which in this context make no sense)
The purpose was and is to demonstrate what can be done with the tools that TechDraw has, this was and is the meaning of the example drawing.

But I also understand that "chrisb" did it without hurting me

As a wise moderator he should have appreciated and suggest me to describe step by step how I did it, surely it would have helped “RSA” much more.
Regarding the smaps in TechDraw, we have the humility to say: sorry, your proposal is valid but at present we are not able to turn it into code because it would also involve a lot of additional work.

Developers, users of any level, translators, front end designers, etc. we are all in the same "boat", everyone can say nonsense things but not because you are a developer you are privileged, we all contribute to what our knowledge allows us.

In any case, certainly from this controversy we have all drawn something positive for the good of FreeCad, therefore i consider the controversy closed here.

Good job everyone!
User avatar
wandererfan
Posts: 4078
Joined: Tue Nov 06, 2012 5:42 pm

Re: Center of circle relative to edge.

Postby wandererfan » Sat Aug 29, 2020 4:53 pm

domad wrote:
Thu Aug 27, 2020 7:02 am
wouldn't it be better if instead of using the "cosmetic" vertices, snaps were implemented to insert the dimensions in TechDraw?
Apologies for being so late to this party.

After git commit 08ba104d87 curved edges are accepted as input to linear dimensions. This may address the issue raised in the initial post.
CurvedEdgeLinearDims.png
CurvedEdgeLinearDims.png (27.27 KiB) Viewed 380 times
I am not sure that cosmetic geometry and snaps are mutually exclusive. Surely there will be times when a required reference point is not "snappable", but can be defined geometrically. Also, I expect cosmetic geometry will be useful in specifying dimension endpoints that do not already have a geometry element (ex inserting a cosmetic vertex at midpoint of an edge).

There main reason that snapping has not been implemented is that there has not been a request(??) for it until now. issue #4227 has some similarities, but is not quite "snapping".

I will investigate what is required in the way of coding changes, but it would be helpful if some one was to articulate a few specific use cases.
aapo
Posts: 213
Joined: Mon Oct 29, 2018 6:41 pm

Re: Center of circle relative to edge.

Postby aapo » Sat Aug 29, 2020 9:58 pm

wandererfan wrote:
Sat Aug 29, 2020 4:53 pm
After git commit 08ba104d87 curved edges are accepted as input to linear dimensions. This may address the issue raised in the initial post.
Cool! It even seems to work with elliptical edges, which have often seemed to be problematic in TD. Thanks, this is a good addition :D
20200830_FreeCAD_Elliptic_TD_dims.png
20200830_FreeCAD_Elliptic_TD_dims.png (88.27 KiB) Viewed 355 times

There main reason that snapping has not been implemented is that there has not been a request(??) for it until now. issue #4227 has some similarities, but is not quite "snapping".

I will investigate what is required in the way of coding changes, but it would be helpful if some one was to articulate a few specific use cases.
Well, I didn't first understand what domad meant, but he certainly had a valid point: An ability to "snap" dimensions would have helped in the original user problem, where the user did not know about multi-selection (using ctrl or shift to select more than one point or edge). If "snapping" would have been possible, the user could first have selected an edge, add a dimension, and then "snap" one endpoint to a circle center, and the other one to the desired edge. That way, it would have been possible to make the dimension without using multi-selection.

That kind of functionality would likely be rather unnecessary for a more seasoned user, but being able to "snap" dimensions after they have been first created would certainly also have several valid use cases for all users:
  1. After the dimensions jump around due to the dreaded topological naming problem, it would be faster to fix them if one could drag and snap the endpoints back to more reasonable locations. Especially if the dimensions have some formatting or other options enabled. At the moment the user needs to delete the dimension, re-add it, and then do all the formatting again.
  2. If the user accidentally sets an endpoint to wrong point, drag-and-snap would be an easy way to correct it.
  3. There could be a possibility for temporarily "hanging" dimensions, that are not (yet) fixed anywhere.
  4. It might even be possible to change the dimension type according to what the snapped endpoints would be, e.g. if the other endpoint is a circular edge, and the user snaps the other endpoint to the same edge, it could become a radial dimension (or a diameter for full circle).
  5. Also, this kind of snapping would make it reasonable to include a new command to change the dimension type. At the moment, that would not make much sense, as the endpoints cannot be moved.
Of course, all of these would be convenience features and everything could be done without snapping, too, but I think domad's point was that there are advantages in an efficient and easy user interface, even if it wouldn't add any new functionality.
domad
Posts: 196
Joined: Mon Jun 22, 2020 12:16 pm

Re: Center of circle relative to edge.

Postby domad » Tue Sep 01, 2020 4:04 pm

aapo wrote:
Sat Aug 29, 2020 9:58 pm

Well, I didn't first understand what domad meant, but he certainly had a valid point: An ability to "snap" dimensions would have helped in the original user problem, where the user did not know about multi-selection (using ctrl or shift to select more than one point or edge). If "snapping" would have been possible, the user could first have selected an edge, add a dimension, and then "snap" one endpoint to a circle center, and the other one to the desired edge. That way, it would have been possible to make the dimension without using multi-selection.

That kind of functionality would likely be rather unnecessary for a more seasoned user, but being able to "snap" dimensions after they have been first created would certainly also have several valid use cases for all users:
  1. After the dimensions jump around due to the dreaded topological naming problem, it would be faster to fix them if one could drag and snap the endpoints back to more reasonable locations. Especially if the dimensions have some formatting or other options enabled. At the moment the user needs to delete the dimension, re-add it, and then do all the formatting again.
  2. If the user accidentally sets an endpoint to wrong point, drag-and-snap would be an easy way to correct it.
  3. There could be a possibility for temporarily "hanging" dimensions, that are not (yet) fixed anywhere.
  4. It might even be possible to change the dimension type according to what the snapped endpoints would be, e.g. if the other endpoint is a circular edge, and the user snaps the other endpoint to the same edge, it could become a radial dimension (or a diameter for full circle).
  5. Also, this kind of snapping would make it reasonable to include a new command to change the dimension type. At the moment, that would not make much sense, as the endpoints cannot be moved.
Of course, all of these would be convenience features and everything could be done without snapping, too, but I think domad's point was that there are advantages in an efficient and easy user interface, even if it wouldn't add any new functionality.
Greetings to the whole community!
I apologize for my absence, but I have had commitments.
Thanks “aapo” for your interpretation.
In the image, some simple examples of using Draft and snapping in TechDraw
1 - "Draft" tools to draw various objects to increase the degree of technical definition of the drawing and to draw closed polylines to define the window-model area on the page;
2 - tools to allow editing of Draft objects;
3 - function creates window on model view from polyline; windows can be moved and resized graphically in the sheet using Draft snaps and editing tools;
4 - functions create fill region and create custom fills;
5 - snaps to hook any element of the page and of the object contained in the model window, including the dimensioning of the view and window object;
If the developers find them interesting they could develop them and expand the productivity (speed of execution) and accuracy of FreeCad making it more professional.
Attachments
Snap_Draft_in_techdraw.png
Snap_Draft_in_techdraw.png (145.65 KiB) Viewed 258 times
Last edited by domad on Tue Sep 01, 2020 6:28 pm, edited 1 time in total.
chrisb
Posts: 29060
Joined: Tue Mar 17, 2015 9:14 am

Re: Center of circle relative to edge.

Postby chrisb » Tue Sep 01, 2020 6:05 pm

Please dont quote complete posts - or even discussions. Limit the quotes to the parts you are directly referring to. It's easier to follow.
A Sketcher Lecture with in-depth information is available in English, auf deutsch, en français, en español.
domad
Posts: 196
Joined: Mon Jun 22, 2020 12:16 pm

Re: Center of circle relative to edge.

Postby domad » Tue Sep 01, 2020 6:31 pm

chrisb wrote:
Tue Sep 01, 2020 6:05 pm
Please dont quote complete posts - or even discussions. Limit the quotes to the parts you are directly referring to. It's easier to follow.
I corrected, sorry for the oversight, thanks chrisb!