kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 03/11/2011 10:31 AM, Wayne Stambaugh wrote:
> I've finally got the EESchema drawing object hit testing code to the point
> where it can support hit testing for multiple objects.  It should not be
> terribly difficult task as this point (famous last words) to implement an
> object clarification context menu similar to PCBNew when multiple objects are
> at the current cursor position.  I remember this being discussed a long time
> ago but I couldn't find anything useful when I searched the mailing list so I
> thought I would get some input before I proceeded any further.  Is this
> something that users would find useful or annoying?  It certainly would be more
> consistent with the behavior of PCBNew.  Those who have used EESchema for a
> long time may find the changes disconcerting.  I would like to get a feel for
> how users feel about this change so I don't spend time implementing something
> no one wants.  It would also be helpful if someone can post this on the Kicad
> users mailing list and summarize the discussion.
>
> Wayne

I think with the combination of solid hit testing and the Collector design
pattern that I introduced in PCBNEW, you have the basis to craft a number of
UIs on top of it.  The collector can be tailored (even dynamically) to look
for subsets of object types.  So if you wanted to have a specialized mouse
tool that only paid attention to objects of a particular kind, or objects of
kinds selected from a checkbox panel, all this can be done using the
Collector design pattern.  I even used it in the specctra_export extensively
as an alternative to list walking.

So with those two building blocks, you can craft the behavior desired for
the UI.

The only thing I would say about hit-testing is that there was some recent
discussion about text fields which were "far away" from the base object, and
that this would expand the bounding box in unexpected ways, leading to
unexpected object selections.


To address that one would be tempted to consider a design pattern where
instead of having a single bounding box, that we have a list of bounding
boxes, per *base/major* (not sub-object) object.  So the text field, only if
it was far enough away from its base object, would contribute an additional
bounding box to the list of bounding boxes held by the base object. 
Otherwise, if it was close enough, then it would contribute nothing, and
maybe the list of bounding boxes would be reduced, possibly down to a
minimum list size of one bounding box.


But here's a better observation:  if the Collector design pattern is used
religiously everywhere, then all sub-objects such as text fields get
collected as a natural consequence of the current Collector selectivity in
play at that moment, and you do not need the list of bounding boxes, because
you would hit test every object and sub-object anyway, and only collect it when:

   its hittest hits AND it is in the selectivity list;
   ( a logical AND )


For this to be effective, the bounding box of the base object would need to
EXCLUDE the bounding boxes of the sub-objects, e.g. text fields, and I don't
know that we currently do that.  So this is perhaps a needed change, keep
every bounding box specific to the object that holds it, and exclude its
child sub-objects.


Again, the Collector design pattern is solid.   It is only a matter of
figuring out how to apply it in a way that constitutes a friendly UI.  So
figuring out those tuning knobs can be done over time, getting the Collector
design pattern in place seems like a safe start in any case.   Again, doing
that also means simplifying the bounding box concept to exclude child
objects, since the Collector will "visit" all those child objects
individually to see what needs to be "collected".


Dick