kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 3/14/2011 2:02 PM, Dick Hollenbeck wrote:
> 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'll probably step out on that limb over the next couple of weeks.  I think
it's safe to say that I'll find out pretty quickly how many users don't like
the new behavior.

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

I was planning on using the PCBNew behavior to maintain consistency between
applications.

Thanks for the input.

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
>