[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
gEDA-cvs: pcb.git: branch: master updated (8d112eee91986eecffc882ff2116dd281e476e68)
The branch, master has been updated
via 8d112eee91986eecffc882ff2116dd281e476e68 (commit)
via 0c849e2bdbbc592a3bf5c1d28571b82efec42a17 (commit)
via d7dc68fddf0324f5601b2c54fa82df20ae4fa81a (commit)
from b90fb6ae22ae83fdc0c802268dcbe74005bc705e (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
=========
Summary
=========
src/crosshair.c | 6 +++---
src/search.c | 37 +++++++++++++++++++++++--------------
2 files changed, 26 insertions(+), 17 deletions(-)
=================
Commit Messages
=================
commit 8d112eee91986eecffc882ff2116dd281e476e68
Author: Peter Clifton <pcjc2@xxxxxxxxx>
Commit: Peter Clifton <pcjc2@xxxxxxxxx>
search.c: Return the pad who's center is closest to the queried coordinate
When snapping to pads we often find the case where the search radius is
wider than the spacing between pads. SearchPadByLocation() previously
returned the first pad it found whthin the search area, meaning you could
have the crosshair right above a particular pad, yet snap to a different
pad due to it being within the search radius of the crosshair, and
happening to be tested first by the r-tree search code.
This proof of concept change makes SearchPadByLocation() return the pad
whos center coordinate is closest to the center of the search location.
This fixes another annoying snapping behaviour for some parts such as
"0805", when operating with a fairly course grid. (NB: Search radius
for snapping is related to the size of the current grid).
:100644 100644 5d02a53... 5417462... M src/search.c
commit 0c849e2bdbbc592a3bf5c1d28571b82efec42a17
Author: Peter Clifton <pcjc2@xxxxxxxxx>
Commit: Peter Clifton <pcjc2@xxxxxxxxx>
crosshair.c: Be paranoid about overflow when finding an pad-center coordinates
Not aiming to fix any particular bug here, but I noticed the potential
overflow here and thought I'd fix it. Longer term, we perhaps ought to write
some convenience functions for performing operations like this correctly.
:100644 100644 3c6c46e... a644cc7... M src/crosshair.c
commit d7dc68fddf0324f5601b2c54fa82df20ae4fa81a
Author: Peter Clifton <pcjc2@xxxxxxxxx>
Commit: Peter Clifton <pcjc2@xxxxxxxxx>
crosshair.c: Snap to later-tested objects equi-distant with the current snap.
This inequality adjustment means that when an element mark is on-grid, and
the first-snap is a grid location snap, the test against the element mark
will now pass, and mark the snap as a non-grid snap.
This fixes the rather irritating bug where certain footprints, such as SMT
resistors became impossible to grab by their element mark when that mark
landed exactly on a grid point.
:100644 100644 b7bebec... 3c6c46e... M src/crosshair.c
=========
Changes
=========
commit 8d112eee91986eecffc882ff2116dd281e476e68
Author: Peter Clifton <pcjc2@xxxxxxxxx>
Commit: Peter Clifton <pcjc2@xxxxxxxxx>
search.c: Return the pad who's center is closest to the queried coordinate
When snapping to pads we often find the case where the search radius is
wider than the spacing between pads. SearchPadByLocation() previously
returned the first pad it found whthin the search area, meaning you could
have the crosshair right above a particular pad, yet snap to a different
pad due to it being within the search radius of the crosshair, and
happening to be tested first by the r-tree search code.
This proof of concept change makes SearchPadByLocation() return the pad
whos center coordinate is closest to the center of the search location.
This fixes another annoying snapping behaviour for some parts such as
"0805", when operating with a fairly course grid. (NB: Search radius
for snapping is related to the size of the current grid).
diff --git a/src/search.c b/src/search.c
index 5d02a53..5417462 100644
--- a/src/search.c
+++ b/src/search.c
@@ -106,6 +106,8 @@ struct ans_info
double area;
jmp_buf env;
int locked; /* This will be zero or LOCKFLAG */
+ bool found_anything;
+ double nearest_sq_dist;
};
static int
@@ -182,19 +184,28 @@ pad_callback (const BoxType * b, void *cl)
PadTypePtr pad = (PadTypePtr) b;
struct ans_info *i = (struct ans_info *) cl;
AnyObjectType *ptr1 = pad->Element;
+ double sq_dist;
- if (TEST_FLAG (i->locked, ptr1))
+ /* Reject locked pads, backside pads (if !BackToo), and non-hit pads */
+ if (TEST_FLAG (i->locked, ptr1) ||
+ (!FRONT (pad) && !i->BackToo) ||
+ !IsPointInPad (PosX, PosY, SearchRadius, pad))
return 0;
- if (FRONT (pad) || i->BackToo)
+ /* Determine how close our test-position was to the center of the pad */
+ sq_dist = (PosX - (pad->Point1.X + (pad->Point2.X - pad->Point1.X) / 2)) *
+ (PosX - (pad->Point1.X + (pad->Point2.X - pad->Point1.X) / 2)) +
+ (PosY - (pad->Point1.Y + (pad->Point2.Y - pad->Point1.Y) / 2)) *
+ (PosY - (pad->Point1.Y + (pad->Point2.Y - pad->Point1.Y) / 2));
+
+ /* If this was the closest hit so far, record it */
+ if (!i->found_anything || sq_dist < i->nearest_sq_dist)
{
- if (IsPointInPad (PosX, PosY, SearchRadius, pad))
- {
- *i->ptr1 = ptr1;
- *i->ptr2 = *i->ptr3 = pad;
- longjmp (i->env, 1);
- }
- }
+ *i->ptr1 = ptr1;
+ *i->ptr2 = *i->ptr3 = pad;
+ i->found_anything = true;
+ i->nearest_sq_dist = sq_dist;
+ }
return 0;
}
@@ -216,11 +227,9 @@ SearchPadByLocation (int locked, ElementTypePtr * Element, PadTypePtr * Pad,
info.ptr3 = (void **) Dummy;
info.locked = (locked & LOCKED_TYPE) ? 0 : LOCKFLAG;
info.BackToo = (BackToo && PCB->InvisibleObjectsOn);
- if (setjmp (info.env) == 0)
- r_search (PCB->Data->pad_tree, &SearchBox, NULL, pad_callback, &info);
- else
- return true;
- return false;
+ info.found_anything = false;
+ r_search (PCB->Data->pad_tree, &SearchBox, NULL, pad_callback, &info);
+ return info.found_anything;
}
/* ---------------------------------------------------------------------------
commit 0c849e2bdbbc592a3bf5c1d28571b82efec42a17
Author: Peter Clifton <pcjc2@xxxxxxxxx>
Commit: Peter Clifton <pcjc2@xxxxxxxxx>
crosshair.c: Be paranoid about overflow when finding an pad-center coordinates
Not aiming to fix any particular bug here, but I noticed the potential
overflow here and thought I'd fix it. Longer term, we perhaps ought to write
some convenience functions for performing operations like this correctly.
diff --git a/src/crosshair.c b/src/crosshair.c
index 3c6c46e..a644cc7 100644
--- a/src/crosshair.c
+++ b/src/crosshair.c
@@ -1026,8 +1026,8 @@ FitCrosshairIntoGrid (Coord X, Coord Y)
if (ans != NO_TYPE)
{
PadType *pad = (PadType *)ptr2;
- check_snap_object (&snap_data, (pad->Point1.X + pad->Point2.X) / 2,
- (pad->Point1.Y + pad->Point2.Y) / 2,
+ check_snap_object (&snap_data, pad->Point1.X + (pad->Point2.X - pad->Point1.X) / 2,
+ pad->Point1.Y + (pad->Point2.Y - pad->Point1.Y) / 2,
true);
}
commit d7dc68fddf0324f5601b2c54fa82df20ae4fa81a
Author: Peter Clifton <pcjc2@xxxxxxxxx>
Commit: Peter Clifton <pcjc2@xxxxxxxxx>
crosshair.c: Snap to later-tested objects equi-distant with the current snap.
This inequality adjustment means that when an element mark is on-grid, and
the first-snap is a grid location snap, the test against the element mark
will now pass, and mark the snap as a non-grid snap.
This fixes the rather irritating bug where certain footprints, such as SMT
resistors became impossible to grab by their element mark when that mark
landed exactly on a grid point.
diff --git a/src/crosshair.c b/src/crosshair.c
index b7bebec..3c6c46e 100644
--- a/src/crosshair.c
+++ b/src/crosshair.c
@@ -819,7 +819,7 @@ check_snap_object (struct snap_data *snap_data, Coord x, Coord y,
double sq_dist;
sq_dist = crosshair_sq_dist (snap_data->crosshair, x, y);
- if (sq_dist < snap_data->nearest_sq_dist ||
+ if (sq_dist <= snap_data->nearest_sq_dist ||
(prefer_to_grid && snap_data->nearest_is_grid && !gui->shift_is_pressed()))
{
snap_data->x = x;
_______________________________________________
geda-cvs mailing list
geda-cvs@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-cvs