Fix issue161 and 174. Use the same logic for selction and dragging, b…#672
Fix issue161 and 174. Use the same logic for selction and dragging, b…#672phkahler merged 1 commit intosolvespace:masterfrom
Conversation
|
This does not work as well as current master for dragging lines in the underlying sketch. We could probably expand the idea to cover those (line with an immovable point could be skipped maybe?). Might need some refactoring too. Just want to know if this heading in the right direction and how far to go with it. |
|
The latest version of this splits the draggability decision out into a funtion EntityBase::CanBeDragged(). Points, Lines, Arcs, and Beziers can all be dragged in an underlying sketch if they are not fully constrained. This particular issue with drag being greedy is resolved by dragging whichever point hover/select would have picked. In this case neither of those points is considered "undraggable" so whichever one is hovered/highlighted will be the one selected for dragging. |
|
This should probably live in Entity, not EntityBase, since it is an UI concern. |
…ut ignore entites that are inherently undraggable. This allows the selection to reach through entities to their corresponding ones on the underlying sketch which can be dragged if they are not fully constrained. This is decided in a new function Entity::CanBeDragged().
|
Moved it. Also added circles to the list because they weren't resizing in the base sketch when dragged. |
|
@phkahler I just tested this PR and this is an excellent solution to several longstanding issues. Thank you! |
2 participants
This would be used instead of PR #658 because it fixes both issues while preserving the ability to drag underlying sketch points.