summaryrefslogtreecommitdiffstats
path: root/src/snap.cpp (follow)
Commit message (Collapse)AuthorAgeFilesLines
* When snapping only the closest node, draw an indicator at that nodeDiederik van Lierop2008-11-261-37/+90
| | | (bzr r6903)
* Add an option to the preferences to _only_ snap the node closest to the ↵Diederik van Lierop2008-11-241-3/+2
| | | | | mouse pointer (bzr r6899)
* 1) Improve the way the distance to the pointer is taken into account when ↵Diederik van Lierop2008-11-231-16/+19
| | | | | | | | finding the best snap 2) Use this distance also when snapping nodes in the path editor 3) Add a slider in the preferences dialog to control the weighing of this distance (bzr r6895)
* Merge from fe-movedTed Gould2008-11-211-10/+10
| | | (bzr r6891)
* Merge from trunkTed Gould2008-10-311-7/+16
| | | (bzr r6887)
* From trunkTed Gould2008-10-271-88/+25
| | | (bzr r6885)
* Merging from trunkTed Gould2008-10-111-8/+26
| | | (bzr r6884)
* - refactor snapping code, removing code duplicationDiederik van Lierop2008-09-211-62/+48
| | | | | - fix snapping to page corners (bzr r6863)
* If a snapper needs a reference to a SPNamedView or a SPDesktop, then get ↵Diederik van Lierop2008-09-071-2/+7
| | | | | that reference via the SnapManager (instead of storing references in the snapper and accessing them directly) (bzr r6773)
* Remove pointer to SPDesktop from ObjectSnapperDiederik van Lierop2008-09-071-3/+1
| | | (bzr r6772)
* Eliminate SP_ACTIVE_DESKTOP in the object-snapperDiederik van Lierop2008-08-301-1/+3
| | | (bzr r6730)
* Modify the parameters required for setting up the SnapManagerDiederik van Lierop2008-08-281-9/+13
| | | (bzr r6722)
* Move all of the snapper code to 2geomDiederik van Lierop2008-08-111-68/+68
| | | (bzr r6606)
* Snap to intersections of any kind of path (were we previously only could ↵Diederik van Lierop2008-08-081-9/+10
| | | | | snap to intersections of line-segments) (bzr r6597)
* remove many unnecessary to_2geom and from_2geom callsJohan B. C. Engelen2008-08-081-1/+1
| | | (bzr r6593)
* 1) When pasting, use an offset that is a multiple of the grid pitch (got ↵Diederik van Lierop2008-08-061-0/+54
| | | | | | | lost during a previous round of refactoring) 2) Refactor some of the pasting code (bzr r6580)
* NR::Maybe => boost::optionalJohan B. C. Engelen2008-08-051-4/+4
| | | (bzr r6569)
* Fix snapping for constrained translation in the selector toolDiederik van Lierop2008-05-201-1/+7
| | | (bzr r5722)
* Fix a regression in the snapper, caused by me. Sorry!Diederik van Lierop2008-05-161-2/+2
| | | (bzr r5680)
* Add a centralized check (i.e. in the snapper mechanism) whether we've ↵Diederik van Lierop2008-05-121-4/+47
| | | | | snapped or not, instead of leaving it up to the various tools. This should prevent these tools from moving to (0,0) if they bluntly use the value returned by the snapping mechanism without checking whether snapping has really occured. (bzr r5659)
* Next steps in implementing the snapping indicatorDiederik van Lierop2008-05-041-5/+10
| | | (bzr r5600)
* Replace freeSnapSkew() by constrainedSnapSkew(). There is no such thing as ↵Diederik van Lierop2008-05-011-10/+17
| | | | | freely snapping while skewing; snapping will always be constrained (bzr r5569)
* - Major refactoring of snapping related code...Diederik van Lierop2008-04-301-141/+100
| | | | | - Enabling snap indicator for all remaining tools (bzr r5556)
* Refactor snapping mechanisms: in seltrans.cpp, a GSList was converted to a ↵Diederik van Lierop2008-04-111-15/+21
| | | | | std::list in four different places. Now this is handled in only one place (bzr r5407)
* Refactor snapper and snapindicator (in order to enable the snapindicator in ↵Diederik van Lierop2008-04-071-83/+72
| | | | | the selector tool) (bzr r5374)
* Major overhaul of the selector tool's internals to improve handling of ↵Diederik van Lierop2008-03-251-2/+3
| | | | | transformations, origins and snapping, for both visual and geometric bounding boxes (see for example bug #174046 in Launchpad) (bzr r5189)
* Node tool: snap to paths and their nodes, incl. to the path currently being ↵Diederik van Lierop2008-03-081-4/+38
| | | | | edited (bzr r4989)
* Fix #181795Diederik van Lierop2008-01-121-28/+17
| | | (bzr r4471)
* (bzr r4464)Diederik van Lierop2008-01-111-7/+6
|
* Fix LP #181020: When snapping a guide, now only the part of the guide near ↵Diederik van Lierop2008-01-081-1/+1
| | | | | the pointer is considered (bzr r4435)
* 1) fix snapping while scalingDiederik van Lierop2008-01-031-70/+107
| | | | | | | 2) fix constrained snapping 3) improve snapping logic (again), or more specifically: better obey "always snap" 4) refactoring to reduce risk of bugs: renaming variables and methods for better readability, adding class members instead of using std::pairs, etc. (bzr r4379)
* Fix snapping when constrained scaling: now snaps all corners of the selectionDiederik van Lierop2007-12-281-12/+34
| | | (bzr r4328)
* Snapping a guide to nodes (while dragging it across the canvas) now also ↵Diederik van Lierop2007-12-271-18/+5
| | | | | works for angled guides (bzr r4321)
* 1) Fix bug #178312Diederik van Lierop2007-12-271-6/+33
| | | | | 2) Fix constrained snapping to objects (bzr r4314)
* 1) solve bug #177995Diederik van Lierop2007-12-221-21/+35
| | | | | 2) don't look for nearby intersections when doing a constrained snap (bzr r4275)
* Add global snapping toggleDiederik van Lierop2007-12-121-4/+10
| | | (bzr r4221)
* 1) Improving snapping logic 2) When skewing, don't snap to selection itselfDiederik van Lierop2007-11-181-25/+22
| | | (bzr r4111)
* Improving snapping logic; more to followDiederik van Lierop2007-11-181-5/+21
| | | (bzr r4102)
* A pasted selection is supposed to snap to the grid, but this cannot work the ↵Diederik van Lierop2007-11-141-54/+0
| | | | | | | way its implemented currently. If one of the points is currently snapped, then how can we make sure that that SAME point is snapped again after pasting? If it's another point that snaps, then this is useless... Furthermore it's also buggy currently (it messes up the grid snapping sensitivity), so I'm removing this functionality. If someone wants it back, we should rather round the paste offset to a multiple of the grid pitch. This way, something that was snapped to the grid before will stay snapped after pasting. (bzr r4083)
* Snap to intersections of line segmentsDiederik van Lierop2007-11-141-6/+26
| | | (bzr r4082)
* Renaming classes: SnappedLine -> SnappedLineSegment, and SnappedInfiniteLine ↵Diederik van Lierop2007-11-091-7/+7
| | | | | -> SnappedLine (bzr r4048)
* Improve the user interaction for snapping of bounding boxes, and add an new ↵Diederik van Lierop2007-11-051-5/+10
| | | | | tab in document properties for detailed snapping options (bzr r4033)
* Oops, don't use tabs! (replace tabs by 4 spaces)Diederik van Lierop2007-11-031-112/+112
| | | (bzr r4020)
* Groundwork to snap to intersections, e.g. intersections of gridlines with ↵Diederik van Lierop2007-11-031-53/+111
| | | | | guidelines, and of objects with other objects. The snappers used to return only SnappedPoints, but now also SnappedLines and SnappedInfiniteLines can be returned. SnappedPaths will be implemented later. (bzr r4016)
* update copyright header to reflect Nathan's work in e.g. r1204MenTaLguY2007-10-111-1/+3
| | | (bzr r3870)
* Also snap new guides, which are being dragged off the ruler.Diederik van Lierop2007-09-071-3/+3
| | | (bzr r3701)
* Improving the performance of the object snapperDiederik van Lierop2007-09-051-21/+55
| | | (bzr r3689)
* Implement snapping of guides while dragging them, and snap TO item centers ↵Diederik van Lierop2007-08-281-0/+27
| | | | | (we only had snapping FROM item centers so far) (bzr r3603)
* Reverting a change I made a while agoDiederik van Lierop2007-08-091-1/+1
| | | (bzr r3441)
* 1) Make snapping of object's center optional 2) Optimize snapping ↵Diederik van Lierop2007-08-061-1/+1
| | | | | preferences dialog (bzr r3399)
generated by cgit v1.2.3 (git 2.25.1) at 2026-05-19 21:25:49 +0000