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