Constraints extended naming

[abdullah]

How too much geek for an exposed option is this?

constraints_extendednaming.png (27.18 KiB) Viewed 3031 times

[chrisb]

Hi Abdullah, additional information is always good. I guess it's information about which elements are affected by the constraints?

[abdullah]

Hi Abdullah, additional information is always good. I guess it's information about which elements are affected by the constraints?

[(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

[triplus]

Likely should be tied to an Advanced checkbox in preferences. Useful for Python developers but likely confusing to an average end user?

[chrisb]

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

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.

[abdullah]

Likely should be tied to an Advanced checkbox in preferences. Useful for Python developers but likely confusing to an average end user?

I surely makes sense. This one is easy to accommodate.

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.

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?

[triplus]

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.

[chrisb]

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?

[bejant]

How too much geek for an exposed option is this?

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

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.

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.

[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?

[abdullah]

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.

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.

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.

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 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.

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.

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:

...

...

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?