kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 03/14/2011 12:18 PM, Wayne Stambaugh wrote:
> 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.

You will never know that, since at best you can only poll a subset.

I don't see a reason to stray too far away from PCBNEW over all feel on this
issue.

Dick