diff --git a/src/conn-avoid-ref.cpp b/src/conn-avoid-ref.cpp
index 540e8205fbbf191e093619c4e60e601c3faa5fa7..657850ec7bf1ba3ebd835ddcce86e654b742f4ee 100644 (file)
--- a/src/conn-avoid-ref.cpp
+++ b/src/conn-avoid-ref.cpp
*/
+#include <cstring>
+#include <string>
#include "sp-item.h"
#include "conn-avoid-ref.h"
-#include "libnr/nr-rect-ops.h"
#include "libavoid/polyutil.h"
#include "libavoid/router.h"
#include "libavoid/connector.h"
-#include "xml/simple-node.cpp"
+#include "xml/node.h"
#include "document.h"
-#include "prefs-utils.h"
-
#include "desktop.h"
#include "desktop-handles.h"
#include "sp-namedview.h"
_transformed_connection.disconnect();
if (new_setting) {
- _transformed_connection = item->connectTransformed(
- sigc::ptr_fun(&avoid_item_move));
-
Avoid::Polygn poly = avoid_item_poly(item);
if (poly.pn > 0) {
+ _transformed_connection = item->connectTransformed(
+ sigc::ptr_fun(&avoid_item_move));
+
const char *id = SP_OBJECT_REPR(item)->attribute("id");
g_assert(id != NULL);
// by the sp_*_update functions, e.g., text.
sp_document_ensure_up_to_date(item->document);
- NR::Maybe<NR::Rect> rHull = item->getBounds(sp_item_i2doc_affine(item));
+ Geom::OptRect rHull = item->getBounds(sp_item_i2doc_affine(item));
if (!rHull) {
return Avoid::newPoly(0);
}
double spacing = desktop->namedview->connector_spacing;
// Add a little buffer around the edge of each object.
- NR::Rect rExpandedHull = NR::expand(*rHull, -spacing);
+ Geom::Rect rExpandedHull = *rHull;
+ rExpandedHull.expandBy(-spacing);
poly = Avoid::newPoly(4);
for (unsigned n = 0; n < 4; ++n) {
- // TODO: I think the winding order in libavoid or inkscape might
- // be backwards, probably due to the inverse y co-ordinates
- // used for the screen. The '3 - n' reverses the order.
- /* On "correct" winding order: Winding order of NR::Rect::corner is in a positive
- * direction, like libart. "Positive direction" means the same as in most of Inkscape and
- * SVG: if you visualize y as increasing upwards, as is the convention in mathematics, then
- * positive angle is visualized as anticlockwise, as in mathematics; so if you visualize y
- * as increasing downwards, as is common outside of mathematics, then positive angle
- * direction is visualized as clockwise, as is common outside of mathematics. This
- * convention makes it easier mix pure mathematics code with graphics code: the important
- * thing when mixing code is that the number values stored in variables (representing y
- * coordinate, angle) match up; variables store numbers, not visualized positions, and the
- * programmer is free to switch between visualizations when thinking about a given piece of
- * code.
- *
- * MathWorld, libart and NR::Rect::corner all seem to take positive winding (i.e. winding
- * that yields +1 winding number inside a simple closed shape) to mean winding in a
- * positive angle. This, together with the observation that variables store numbers rather
- * than positions, suggests that NR::Rect::corner uses the right direction.
- */
- NR::Point hullPoint = rExpandedHull.corner(3 - n);
- poly.ps[n].x = hullPoint[NR::X];
- poly.ps[n].y = hullPoint[NR::Y];
+ Geom::Point hullPoint = rExpandedHull.corner(n);
+ poly.ps[n].x = hullPoint[Geom::X];
+ poly.ps[n].y = hullPoint[Geom::Y];
}
return poly;
}
-void avoid_item_move(NR::Matrix const *mp, SPItem *moved_item)
+void avoid_item_move(Geom::Matrix const */*mp*/, SPItem *moved_item)
{
Avoid::ShapeRef *shapeRef = moved_item->avoidRef->shapeRef;
g_assert(shapeRef);