[Drawkit] Selection behavior with groups

Brad Larson larson at sonoplot.com
Wed Aug 6 15:06:47 PDT 2008


I wasn't properly handling the case where a single item is selected  
and you would want to move the control point.  Sorry about that, a  
revised file is attached.

On Aug 6, 2008, at 2:09 PM, Brad Larson wrote:

> I added an instance variable to the DKSelectAndEditTool,  
> mAllowMultiObjectKnobDrag, as a boolean which is set via  
> setDragsAllObjectsInSelectionWhenDraggingKnob: .  By default, it is  
> NO, but if it is YES,  
> mouseDownAtPoint:targetObject:layer:event:event delegate: will now  
> take that into account and move the selection rather than edit the  
> control point.
>
> I then call
>
> DKSelectAndEditTool *selectTool = [[DKSelectAndEditTool alloc] init];
> [selectTool setDragsAllObjectsInSelectionWhenDraggingKnob:YES];
> [DKDrawingTool registerDrawingTool:selectTool  
> withName:kDKStandardSelectionToolName];
> [selectTool setKeyboardEquivalent:@" " modifierFlags:0];
>
> at the start of my application to override the default selection  
> behavior.  I also had to modify DKToolController, because  
> setDrawing: was not grabbing the selection tool by its name, it was  
> just creating a new one.  This caused different selection behavior  
> on first load of a document.
>
> I apologize if the naming isn't the best, but this approach would  
> seem to add the option of selecting in this fashion for others who  
> wish to have it while preserving the current method as the default.
>
> On Aug 4, 2008, at 7:36 PM, Graham Cox wrote:
>
>> Currently this is the intended behaviour, not because it makes life  
>> difficult (though I accept it does in your case where your objects  
>> are very small) but because for the typical case it is more usable.  
>> If the user has several objects selected but then deliberately  
>> clicks in a knob, the expected behaviour is to operate that knob as  
>> normal (and refocusing the selection onto that one object  
>> beforehand), not move the selected objects. It means that what a  
>> knob represents in terms of behaviour is consistent.
>>
>> The problem you're having is of course, that the knobs start to  
>> overwhelm the objects at very small scales, so it's hard to click  
>> something that isn't a knob.
>>
>> I can suggest a few ways out of this. The behaviour is implemented  
>> by the DKSelectAndEditTool, as part of its mouseDown... method. So  
>> you could modify that to detect a multiple selection and to treat  
>> any knob hits as body hits instead. Maybe also factor in the zoom  
>> scale and/or object size so that at larger scales the usual  
>> behaviour is kept the same. Another option would be to change the  
>> DKKnob scaling ratio and knob size so that the knobs are smaller at  
>> the scales you are working at so they are less likely to get in the  
>> way. You could also implement your own selection/move tool that  
>> ignored knob hits altogether (so you'd have separate tools for  
>> moving objects and editing them). You could also try grouping the  
>> objects and moving the group - that ignores all knobs for objects  
>> within the group (this is more of a workaround than a real solution).
>>
>> If you let me know your preferred approach I can help you out with  
>> specifics.
>>
>> cheers, Graham
>>
>>
>>
>> On 5 Aug 2008, at 9:27 am, Brad Larson wrote:
>>
>>> One thing I encountered today was a difficulty in moving a large  
>>> group selection, which might require a change in the way that  
>>> knobs are selected.  When you select an object with a large number  
>>> of features, you normally can move that group selection by  
>>> clicking and dragging on any of the features within the  
>>> selection.  The problems come in when you have a group selection  
>>> and click and drag on a knob from one of the selected objects.   
>>> It's been my experience in other draw programs that this would  
>>> also cause a dragging of the whole selection, but in DrawKit that  
>>> currently causes the selection to be lost and for you to edit the  
>>> object by dragging that control point.
>>>
>>> This really causes a problem with groups containing many fine  
>>> features, as often the knobs will be the only thing in the  
>>> selection that you can click on to move it.  For example, in the  
>>> Beta of SonoDraw, try loading the sample PCBExample.pattern,  
>>> enlarging the canvas, selecting all objects, copying and pasting  
>>> another group of objects, then moving the selection.  It is very  
>>> difficult to do unless you zoom way in and select a non-knob part  
>>> of one of the lines.
>>>
>>> This seems like something that is fundamental in the functioning  
>>> of the DKKnob, so I didn't know where to start with modifications  
>>> or even if they were  desired.  Do you prefer this method of  
>>> selection / editing?
>>
>> _______________________________________________
>> Drawkit mailing list
>> Drawkit at lists.apptree.net
>> http://lists.apptree.net/listinfo.cgi/drawkit-apptree.net
>
> ______________________
> Brad Larson
> SonoPlot, Inc.
> 3030 Laura Lane, Suite 120
> Middleton, WI 53562
>
>
> < 
> DKSelectAndEditTool 
> .h 
> > 
> < 
> DKSelectAndEditTool 
> .m><DKToolController.m>_______________________________________________
> Drawkit mailing list
> Drawkit at lists.apptree.net
> http://lists.apptree.net/listinfo.cgi/drawkit-apptree.net

______________________
Brad Larson
SonoPlot, Inc.
3030 Laura Lane, Suite 120
Middleton, WI 53562
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DKSelectAndEditTool.m
Type: application/octet-stream
Size: 38768 bytes
Desc: not available
URL: <http://lists.apptree.net/pipermail/drawkit-apptree.net/attachments/20080806/eb3cc3ec/attachment-0001.obj>
-------------- next part --------------





More information about the Drawkit mailing list