kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 3/14/2011 11:25 AM, Dick Hollenbeck wrote:
> 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.

Object filtering is already part of the schematic object hit testing and there
is now a hit test method in the schematic screen object for returning a list
items found.  It is now just a matter of deciding what to do when multiple
items are found at the current hit test position.

> 
> 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.

This has always been problematic to some extent.  I think this was one of those
pragmatic choices made by design of the original hit testing code.

> 
> 
> 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.

This certainly makes sense to me.  If a component field is outside the
component's bounding box, I think it's reasonable to assume that the field was
what the user was trying to select.  Conversely, if the field bounding box
overlaps the component bounding box and hit test picks up both the field and
the component, the user may be attempting to select either object.

> 
> 
> 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".

This is reason I threw the question out there.  It should be fairly trivial now
to make the internal changes.  It now becomes a matter of how do we implement
this at the UI level.  Is a clarification context menu ( like PCBNew )
appropriate or is there better way to handle this?  I'm open to suggestion on
this one.  My concern is that even though I think improving the hit testing to
support multiple items is a good idea, I don't want to spend a lot of time
improving something that no one else wants.  It seems to me that any changes to
support multiple item hit testing will result in a significant change in the
behavior of EESchema that users may not like.  The real question is would the
majority of users see this as an improvement or not.

Wayne

> 
> 
> Dick
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>