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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
