conn-avoid-ref.cpp revision 346e04ed09c725332769b32af3467056b50cb3bf
/*
* A class for handling shape interaction with libavoid.
*
* Authors:
* Michael Wybrow <mjwybrow@users.sourceforge.net>
*
* Copyright (C) 2005 Michael Wybrow
*
* Released under GNU GPL, read the file 'COPYING' for more information
*/
#include "sp-item.h"
#include "conn-avoid-ref.h"
#include "libnr/nr-rect-ops.h"
#include "libavoid/polyutil.h"
#include "libavoid/connector.h"
#include "xml/simple-node.cpp"
#include "document.h"
#include "prefs-utils.h"
#include "desktop.h"
#include "desktop-handles.h"
#include "sp-namedview.h"
#include "inkscape.h"
, setting(false)
, new_setting(false)
{
}
SPAvoidRef::~SPAvoidRef()
{
if (shapeRef) {
// shapeRef is finalised by delShape,
// so no memory is lost here.
}
}
{
if (SP_OBJECT_IS_CLONED(item)) {
// Don't keep avoidance information for cloned objects.
return;
}
new_setting = false;
new_setting = true;
}
}
void SPAvoidRef::handleSettingChange(void)
{
return;
}
if (new_setting == setting) {
// Don't need to make any changes
return;
}
if (new_setting) {
// Get a unique ID for the item.
}
}
else
{
// shapeRef is finalised by delShape,
// so no memory is lost here.
}
}
{
g_warning("getAttachedShapes: Object with id=\"%s\" is not "
"found. Skipping.", connId);
continue;
}
}
return list;
}
{
g_warning("getAttachedConnectors: Object with id=\"%s\" is not "
"found. Skipping.", connId);
continue;
}
}
return list;
}
{
// TODO: The right way to do this is to return the convex hull of
// the object, or an approximation in the case of a rounded
// object. Specific SPItems will need to have a new
// function that returns points for the convex hull.
// For some objects it is enough to feed the snappoints to
// some convex hull code, though not NR::ConvexHull as this
// only keeps the bounding box of the convex hull currently.
// TODO: SPItem::invokeBbox gives the wrong result for some objects
// that have internal representations that are updated later
// by the sp_*_update functions, e.g., text.
// Add a little buffer around the edge of each object.
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.
*/
}
return poly;
}
bool initialised)
{
if (SP_IS_ITEM(child) &&
)
{
}
}
}
return list;
}
{
}
}
{
// Don't count this as changes to the document,
// it is basically just llate initialisation.
bool initialised = false;
}
if (items) {
}
}
/*
Local Variables:
mode:c++
c-file-style:"stroustrup"
c-file-offsets:((innamespace . 0)(inline-open . 0)(case-label . +))
indent-tabs-mode:nil
fill-column:99
End:
*/
// vim: filetype=cpp:expandtab:shiftwidth=4:tabstop=8:softtabstop=4 :