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'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 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
previous month october 2005 next month
MTWTFSS
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
Go to today