wmayer wrote:abdullah wrote:Group locking
Same example, just select all the centers of all the poles. Now select the origin. Now hit the lock constraint.
This implementation has a weakness when applying it on a rectangle.
- Create a rectangle
- Select the four corners
- Select the origin
- Press the lock button
On the screen it looks like it added four constraints but in fact it added eight and always two constraint symbol lie on each other which makes it hard to select and remove the redundant ones.
Werner, you have asked the sketcher for trouble
and the sketcher has delivered!!
Seriously, now that you raised the point, maybe the problem is my expectations of the locking constraint. I expect a vertical + horizontal constraint on that point (probably because it is what it has historically done). I also expect it to not avoid, not even obvious redundancies (create a point, make a horizontal distance constraint on it. Now ask to lock the point. Redundant horizontal distance constraint created). From that point of view, the implementation for groups is neither better, nor worse than the original, but an extension to several geometries. The user must know what it is asking for or face the consequences... which potentially are of a greater scale, as more points are being constraint at the same time. When using the lock constraint, I personally would have selected two diagonal vertices and ask for a lock on those two.
However, now that you raised the point, I realise that "locking" for a user may mean "do whatever you have to do to make that thing locked and do not bring problems back to me". My view on this is that
general point locking (for Geompoints and non-geompoint vertex without incurring in redundancies) can not be achieved without specialised solver information not available at this point (and subject to working in the regions where the solver works well for rank determination). If only, because there are infinite number of constraint combinations that would indirectly create a redundancy.
For
full geometries, I have another mini-feature in mind, which makes use of solver ability to fix the parameters of a shape. A full geometry would then behave as it were an external geometry. This solves part of the use cases (locking a full bspline in place, while allowing the remaining part of the sketch to be normally edited). However, it does not solve the locking of non-geompoints vertex (e.g. endpoints of line, or center of a circle). For those, we still need the current distanceX, distanceY implementation.
All this to say:
1.
I do not see how I can meaningfully improve the proposed commit implementation (I welcome any proposal of improvement).
2. In view of the other planed mini-feature, we need to differentiate or integrate in the UI (between) a "Fix geometry" constraint/assisting tool and the current "lock" constraint. If the general feeling is that they can achieve symbiosis under the same icon (geompoints will be locked via the yet to be implemented mini-feature; vertex not being a geompoint via traditional way), then they may be integrated together. If not, separate icons, names will have to be provided. In the latter case, it may we worth thinking whether we want to keep the "lock" name for the current implementation. A possibility is to cede the "lock" name to the yet to be implemented mini-feature and make a new name for the traditional "horizontal/vertical lock". Of course, that also raises issues as users are used to a terminology, icons and have expectations too
I think it would be great to find right terminology for both. If I were to propose, I would opt to call the latter "lock" and find a new name for the current distancex-distancey implementation more in accordance with what it actually is.