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

[David Gobbi]

On Sun, Jan 10, 2010 at 3:40 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:
>
> David,
>
> I have a two other comments about the changes that I did not mention
> before (since they are more complicated...)
>
> 1) You store the return value of addTrackingRect: in the
> rolloverTrackingRectTag ivar (fine), but you assume that it will only
> return positive values (see clearTrackingRect).  No doubt this is the
> case currently, but I can't find anything in the docs to indicate that
> this can be assumed.  Maybe I've just missed it?

As far as I could find in the docs, there are no invalid values for
NSTrackingRectTag, so we have to assume that even zero is a valid tag.
 I've added a separate boolean ivar to handle this.


> 2) Why did you decide to use resetCursorRects to add/remove the tracking
> rects?  It doesn't seem to be the typical purpose of resetCursorRects.
> OTOH, from the googling I've done, this is perhaps the best place.
> IMNSHO, Apple's addTrackingRect: API is broken.  An example is this
> statement from Apple's docs:

It's there because Yves saw some similar example code.  And, yeah, it
seems like a good place for it, even if the documentation isn't
specific.


> 10.5 introduced a new class NSTrackingArea which addresses these
> problems, notably "An NSTrackingArea object belongs to its view rather
> than to its window. Consequently, you can add and remove tracking
> rectangles without needing to worry if the view has been added to a window"

Kitware still has dashboard machines running 10.3, so we need to beg
them to upgrade those machines and give us permission to update the
Cocoa code to the newer future-proof APIs.

A related slightly broken item is the HideCursor/ShowCursor in
vtkCocoaRenderWindow.  It hides the cursor globally, but could instead
just set a "blank" cursor like the X11 window does, so that the rects
would only blank the cursor while it was inside the window.


> I propose we:
> A) stick with what we have (but fix #1 above by changing your "> 0" to "!
> = 0").
> or
> B) Increase VTK's minimum requirement to Mac OS X 10.5 and use the newer
> cleaner APIs.

I have committed fix (A), since I don't have the authority for (B).
But hopefully, someday, it will happen.

   David