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