Constraints extended naming
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Constraints extended naming
How too much geek for an exposed option is this?
Re: Constraints extended naming
Hi Abdullah, additional information is always good. I guess it's information about which elements are affected by the constraints?
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: Constraints extended naming
[(GeoId1,PosId1);(GeoId2,PosId2);(GeoId3,PosId3)]
GeoId identifies the element. It is the value you use in Python to identify the geometric element.
PosId is: 0 = the edge, 1 = starting point, 2 = endpoint, 3 = midpoint
Re: Constraints extended naming
Likely should be tied to an Advanced checkbox in preferences. Useful for Python developers but likely confusing to an average end user?
Re: Constraints extended naming
Hovering over a line or arc, the status bar shows something like "Line3". I would rather like to see these names in the list. The numbering starts at 1 as opposed to the python internal counter which starts at 0.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: Constraints extended naming
I surely makes sense. This one is easy to accommodate.
I understand. It is a complicated call.
On one side this will help power python users and developers. Constraint numbering is zero based. This is even in Python (look at the command that is written in the Python console when creating a new constraint using the UI). What the python user/developer sees is what he needs.
On the other side this whole informing sometimes "one" based and other times "zero" based is misleading. Here I also think requiring input "zero based" if informing is "one based" misleading.
Maybe the compromise is to do as triplus says and then assuming that the recipient of the information can process it? any thoughts?
Re: Constraints extended naming
In my opinion when we start talking about Python (power) users it's all about the things like Python API and documentation and on how to improve things there. Therefore i am guessing exposing something intended for Python developers in the GUI is likely targeted at occasional Python users that might find the information useful when trying to write for example a macro. An average end users i could imagine just see some cryptic information when looking at it. Therefore i am not sure to be honest. What is the best strategy to tackle such things. As i am not all that sure if a bunch of "advanced" flags make much sense too. I see them more of a compromise where you have some functionality for some use cases but don't know if enabling it by default makes all that much sense.
Re: Constraints extended naming
I see this additional information rather for the educated end user. When everything is ok I' of course not interested in this informations, but fixing something I had wished in the past to have something like that. Some samples:
- I have coincidences of several arcs and want to remove one of them
- I see a tangent constraint and want to know if it is applied to the endpoints
- I have two coincidences in the center and want to move one of them; which one is to be removed?
- I have coincidences of several arcs and want to remove one of them
- I see a tangent constraint and want to know if it is applied to the endpoints
- I have two coincidences in the center and want to move one of them; which one is to be removed?
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: Constraints extended naming
I don't think it is too hard to remember what each of the four Posld numbers represents, so whether it starts at 0 or 1 doesn't matter much to me.chrisb wrote: ↑Thu May 24, 2018 10:23 amHovering over a line or arc, the status bar shows something like "Line3". I would rather like to see these names in the list. The numbering starts at 1 as opposed to the python internal counter which starts at 0.abdullah wrote: Wed May 23, 2018 1:16 pm
GeoId identifies the element. It is the value you use in Python to identify the geometric element.
PosId is: 0 = the edge, 1 = starting point, 2 = endpoint, 3 = midpoint
[somewhat off topic:]
If Constraints numbering is zero based, maybe the list of Constraints (what GUI user sees in the Combo View) should not start with "Constraint1", but should instead start with "Constraint" and the next Constraint would be "Constraint001". I guess Sketch numbering starts with 0 but the GUI user simply sees "Sketch" in the history tree, so maybe the Constraints list should be the same way too.
[/off topic]
If this proposed Geold / Posld numbering visibility is implemented, and using Constraint40 in the image from the first post as an example, I'd like to be able to hover the cursor over the "Constraint40 [(37,2), (34,1)]" field in the Constraints list and see Edge 37 and Edge 34 and the Constraint turn yellow in the 3D view (similar to behavior of Elements). Actually clicking the Constraint from the list would only select the Constraint and not the related edges. This way I can see the Constraint and the affected geometry in the 3D view change color without having to actually select anything (and because even after selecting a Coincident Constraint from the list it's sometimes difficult to see which one it is in the 3D view of a complicated Sketch). And, maybe with this highlighting, whether the numbering of Geold items is zero based or one based wouldn't matter so much to the average (non-python) user?
Re: Constraints extended naming
I think we all agree this is for the Python users and debugging (also by the power users that assist in the help forum). However, I would not underestimate the part of the Python users as Python is one of the key core FreeCAD features (great irony that I say this given my poor Python knowledge ).
To me it is a two levels decision: Am I a power user? If yes I want to be shown the checkbox, but I want it to be disabled by default, if no, I do not even want to be shown the checkbox. If yes, when I want to see this information, I will check the checkbox, when I do not want to see it anymore.
I use it mostly for debugging. All these are valid use cases. I imagine it is worthy to facilitate assisting the end-user in the help forum. Sometimes the sketch is wrongly constraint, but it is not immediately apparent requires investigation, this requires time. This may help reducing that time.chrisb wrote: ↑Fri May 25, 2018 7:04 am I see this additional information rather for the educated end user. When everything is ok I' of course not interested in this informations, but fixing something I had wished in the past to have something like that. Some samples:
- I have coincidences of several arcs and want to remove one of them
- I see a tangent constraint and want to know if it is applied to the endpoints
- I have two coincidences in the center and want to move one of them; which one is to be removed?
I do not think the PosId is the main problem, as you indicate, the problem is the zero-starting indices for edges and constraints.
This also happens when in expressions you use .Constraints[0], the indexing for the array is zero-based, like in c++, but this is Constraint1 in the widget.
I do believe this is misleading.
So let's say we go "ok, this is misleading, let's change all the naming so that they are zero based", so Edge0, Constraint0. Then, my question would be how much would this affect the macros that are already coded in Python?
If the effect none or minimal, i.e. just changing the "UI", I can even put myself forward to do it. But I do not know how many macros and even workbenches I might break by doing so. Maybe we can ask some proficient Python users:
looo wrote: ...
Do you see a meaningful impact from changing in the Sketcher, the constraint names from being one-based indices, e.g. Constraint1, Constraint2, to Constraint0, Constraint1; and the same for elements (Edge0, Edge1)? Would you favour such change or not?microelly2 wrote: ...