Some questions about the sketch example...
-
I don't quite understand why this example doesn't handle mouseMoved,
Up and Dragged events...
I get the feeling there is something going on with mouse tracking but
I'm not sure how that works and if it is
faster then processing the moved and dragged events.
I don't see in the code where the software figures out that the user
clicked on a control point of an object
and changes its geometry if the mouse moves or if the user clicked
inside the object and is moving it.
I don't see where in the code the software draws the 'bounding box'
and/or control points for an object.
Many thanks....
Brian. -
> I don't quite understand why this example doesn't handle mouseMoved,
> Up and Dragged events...
> I get the feeling there is something going on with mouse tracking but
> I'm not sure how that works and if it is
> faster then processing the moved and dragged events.
>
> I don't see in the code where the software figures out that the user
> clicked on a control point of an object
> and changes its geometry if the mouse moves or if the user clicked
> inside the object and is moving it.
>
> I don't see where in the code the software draws the 'bounding box'
> and/or control points for an object.
>
> Many thanks....
> Brian.
-
That's an interesting point. Upon closer examination
there only seems to be a mouseDown: method in the
SKTGraphicView.
When I developed my slide editor app, I just used
mouseDown, mouseDragged, and mouseUp. That seems to be
the simplest way to go.
Sketch seems to be using nextEventMatchingMask: from
the NSWindow class to get mouse data. It's unfortunate
the this application has sparse commenting.
--- Brian O'Brien <bobrien...> wrote:
>> I don't quite understand why this example doesn'thttp://lists.apple.com/mailman/options/cocoa-dev/<howlewere...>
> handle mouseMoved,
>> Up and Dragged events...
>> I get the feeling there is something going on with
> mouse tracking but
>> I'm not sure how that works and if it is
>> faster then processing the moved and dragged
> events.
>>
>> I don't see in the code where the software figures
> out that the user
>> clicked on a control point of an object
>> and changes its geometry if the mouse moves or if
> the user clicked
>> inside the object and is moving it.
>>
>> I don't see where in the code the software draws
> the 'bounding box'
>> and/or control points for an object.
>>
>> Many thanks....
>> Brian.
>
> _______________________________________________
> Do not post admin requests to the list. They will be
> ignored.
> Cocoa-dev mailing list
> (<Cocoa-dev...>)
> Help/Unsubscribe/Update your Subscription:
>
>
> This email sent to <howlewere...>
>
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com -
On 16-Oct-05, at 10:41 AM, Ian was here wrote:
> That's an interesting point. Upon closer examination
> there only seems to be a mouseDown: method in the
> SKTGraphicView.
>
It seems that nextEventMatchingMask and theEvent = [ourWindow
nextEventMatchingMask:NSLeftMouseDraggedMask|NSLeftMouseUpMask];
can be used to fetch events from the event queue without having to
exit the mouseDown event. I guess this is pretty easy to implement....
Then you can swallow up the mouse up event or simply not handle it...
Should I worry about what happens when the mouse moves out of the
window?
> When I developed my slide editor app, I just used
> mouseDown, mouseDragged, and mouseUp. That seems to be
> the simplest way to go.
>
> Sketch seems to be using nextEventMatchingMask: from
> the NSWindow class to get mouse data. It's unfortunate
> the this application has sparse commenting.
>
>
>
>
> --- Brian O'Brien <bobrien...> wrote:
>
>
>>> I don't quite understand why this example doesn't
>>>
>> handle mouseMoved,
>>
>>> Up and Dragged events...
>>> I get the feeling there is something going on with
>>>
>> mouse tracking but
>>
>>> I'm not sure how that works and if it is
>>> faster then processing the moved and dragged
>>>
>> events.
>>
>>>
>>> I don't see in the code where the software figures
>>>
>> out that the user
>>
>>> clicked on a control point of an object
>>> and changes its geometry if the mouse moves or if
>>>
>> the user clicked
>>
>>> inside the object and is moving it.
>>>
>>> I don't see where in the code the software draws
>>>
>> the 'bounding box'
>>
>>> and/or control points for an object.
>>>
>>> Many thanks....
>>> Brian.
>>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be
>> ignored.
>> Cocoa-dev mailing list
>> (<Cocoa-dev...>)
>> Help/Unsubscribe/Update your Subscription:
>>
>>
> http://lists.apple.com/mailman/options/cocoa-dev/<howlewere...>
>
>>
>> This email sent to <howlewere...>
>>
>>
>
>
>
>
>
> __________________________________
> Yahoo! Mail - PC Magazine Editors' Choice 2005
> http://mail.yahoo.com
>
-
On Oct 16, 2005, at 10:36 AM, Brian O'Brien wrote:
> tchingMask and theEvent = [ourWindow
> nextEventMatchingMask:NSLeftMouseDraggedMask|NSLeftMouseUpMask];
> can be used to fetch events from the event queue without having to
> exit the mouseDown event. I guess this is pretty easy to
> implement....
> Then you can swallow up the mouse up event or simply not handle it...
Yep.
> Should I worry about what happens when the mouse moves out of the
> window?
As long as the mouse is down, you will still get events even if the
mouse moves outside of the window (both this way and via -
mouseMoved:, -mouseUp: methods if you use that instead).
Hope this helps,
-- Greg -
The Sketch.app example is a descendant of the Draw.app example which
used this hijacking the event loop techniques.
Hijacking the event loop is quite common in Cocoa applications in
part because NeXT and later Apple included examples and documentation
that hijack the event loop. In the past, NeXT justified the behavior
as a performance improvement.
Apple still recommends it: http://developer.apple.com/documentation/
Cocoa/Conceptual/BasicEventHandling/Tasks/HandlingMouseEvents.html
I have never (even on 25MHz systems) seen a noticeable performance
problem with using -mouseDragged: and -mouseUp:. I personally
strongly recommend NOT hijacking the event loop the way Apple
recommends. However, even "Cocoa Programming" includes an example of
this technique in Chapter 15:
- (void)mouseDown:(NSEvent *)theEvent
{
NSPoint windowLocation = [theEvent locationInWindow];
NSPoint location = [self convertPoint:windowLocation fromView:nil];
int clicks = [theEvent clickCount];
NSString *message = [NSString stringWithFormat:
@”Left Mouse Down: location (%f, %f), %d click%@, pressure %
0.2f, number %d\n”,
location.x, location.y, clicks, ((clicks > 1) ? @”s” : @””),
[theEvent pressure], [theEvent eventNumber]];
[[NSApp delegate] appendStringToConsole:message];
if (periodicFlag) {
BOOL repeating = YES;
[NSEvent startPeriodicEventsAfterDelay:2.0 withPeriod:0.5];
while (repeating) {
NSEvent *mouseUp = [NSApp
nextEventMatchingMask:NSLeftMouseUpMask
untilDate:nil inMode:NSEventTrackingRunLoopMode
dequeue:NO];
if (mouseUp) {
repeating = NO;
} else {
NSEvent *periodicEvent = [NSApp
nextEventMatchingMask:NSPeriodicMask
untilDate:nil
inMode:NSEventTrackingRunLoopMode
dequeue:YES];
NSString *message = [NSString stringWithFormat:
@”Periodic Event: number %d\n”,
[periodicEvent eventNumber]];
[[NSApp delegate] appendStringToConsole:message];
}
}
[NSEvent stopPeriodicEvents];
}
} -
On Oct 16, 2005, at 11:24 AM, Erik Buck wrote:
> The Sketch.app example is a descendant of the Draw.app example
> which used this hijacking the event loop techniques.
>
> Hijacking the event loop is quite common in Cocoa applications in
> part because NeXT and later Apple included examples and
> documentation that hijack the event loop. In the past, NeXT
> justified the behavior as a performance improvement.
>
> Apple still recommends it: http://developer.apple.com/documentation/
> Cocoa/Conceptual/BasicEventHandling/Tasks/HandlingMouseEvents.html
>
>
> I have never (even on 25MHz systems) seen a noticeable performance
> problem with using -mouseDragged: and -mouseUp:. I personally
> strongly recommend NOT hijacking the event loop the way Apple
> recommends. However, even "Cocoa Programming" includes an example
> of this technique in Chapter 15:
I would not recommend doing this for performance.
I _would_ recommend doing this in some cases for code clarity. For
instance, if you have a Sketch-like view where a mouse down/drag/up
may be causing the movement of a graphic, or the resizing of a
graphic, or the creation of a new graphic, or a rotation of a
graphic, et cetera, depending upon tool selection or where you clicked.
If you use -mouseDown:/-mouseMoved:/-mouseUp: then you end up with a
lot of temporary state in instance variables and giant switch
statements to do different things on -mouseMoved:/-mouseUp: based on
the current action.
If you manually pull events out of the event loop, then you have
similar -mouseDown: code for determining what action is being taken,
but then you end up calling a -handleGraphicMove:/-
handleGraphicResize:/etc method that has its own event loop that
handles all the needed state locally to the method as you are
wiggling the mouse around.
The result is fewer variables "global" to the view class, and the
code for each type of activity is all in one place instead of being
split into multiple methods with switch cases.
- Greg
