[vtk-developers] Changes to the Carbon and Cocoa interactors

[David Gobbi]

On Thu, Dec 17, 2009 at 5:33 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> On Thu, Dec 17, 2009 at 4:42 PM, Sean McBride <sean at rogue-research.com> wrote:
>> On 12/17/09 9:18 AM, David Gobbi said:
>>
>>>We just finished a slew of changes to the RenderWindowInteractors for
>>>Carbon and Cocoa.  The main goal was to fill the missing features of
>>>these classes wrt the X and Win32 interactors.  People who rely on
>>>these classes should test them to make sure that their applications
>>>still behave as expected. Briefly, the new behaviors of these classes
>>>are as follows:
>>>
>>>1) Mouse behavior: During a drag, MouseMove events continue if the
>>>drag goes outside the window (carbon didn't do this before).  If no
>>>mouse buttons are held down, the events cease when the mouse leaves
>>>the window (cocoa didn't do this before).
>>>
>>>2) EnterEvent and LeaveEvent have been implemented (finally!).
>>>
>>>3) As mentioned in an earlier email, KeySym information is now mostly
>>>compatible with the X and Win32 interactors and with Tk.
>>
>> David,
>>
>> Thanks for posting this notice/warning.  I did a review.  Looks great!
>> Some comments/questions/suggestions:
>>
>> 1) these changes could certainly cause compatibility issues (as is often
>> the case changing superclasses).  Subclasses, like ours, may have
>> assumed that certain methods inherited from NSView were not overridden.
>> For example, before your changes, mouseEntered:, mouseExited:,
>> resetCursorRects, and flagsChanged: were not implemented in
>> vtkCocoaGLView and subclasses may have expected the NSView behaviour
>> (nothing) and now there is some behaviour.  I've updated the
>> documentation in the .h (which was already out of date, but more so
>> after your change).  Still, I don't think this would affect many others,
>> except perhaps the OsiriX folks.
>>
>> 2) is clearTrackingRect a public API?  If not, we should not declare it
>> in the .h.
>>
>> 3) rolloverTrackingRectTag should not be int, but NSTrackingRectTag (not
>> the same on 64 bit).
>>
>> 4) why does 'altDown' match both command and option keys?
>>
>> 5) there were a few spots where you sent 'frame' without ensuring that
>> the pointer was non-nil.  Messaging nil returns undefined structures.  I
>> added checks for paranoia's sake. :)
>>
>> 6) I made other minor changes.
>>
>> My changes are attached, I have not committed to CVS.  Can you review first?
>
>
> Thanks for the feedback.  I'm still green on Cocoa, myself, so your
> expertise is greatly appreciated.
>
> The reason that I have "altDown" matching both "option" and "command"
> is to mimic the Carbon Interactor, which already did things that way.
> In Carbon Interactor there are comments that say "VNC (as well as some
> Mac users) use the command key as 'alt', so map them both."  My
> feeling is that until the RWI includes a separate event for a "Meta"
> modifier, it is expedient to map both keys to "alt", but I don't have
> a very strong opinion one way or another.
>
>   David

Ok, Sean, I've looked through the diffs for your fixes, everything
appears to be in order so I will commit tomorrow after I've compiled
and tested.

In the code, you asked why vtkCocoaRenderWindow just creates an NSView
when ParentId() is set, rather than a vtkCocoaGLView.  The reason is:
this solution is what works the vtkTkRenderWidget and all the VTK
examples that use the vtkTkRenderWidget.  So yeah, I'll add extra
comments to the code to make sure that people know why it is so.

   David