Notes
(0017950) David Gobbi (developer) 2009-10-05 11:42	The bug appears to be fixed in vtk-cvs for tk 8.4.19, but not yet for tk 8.5.7. The following was needed in vtkTkRenderWidget.cxx and vtkTkImageViewerWidget.cxx: 1) I added a type cast to CGrafPtr for TkMaxOSXGetDrawablePort(), this fix is backwards compatible with all versions of TkAqua. 2) The code for finding the (x,y) position relative to the toplevel Carbon window has been changed, it used to use (winPtr->privatePtr->xOff, ...yOff) but this is no longer valid, most likely since TkAqua switched to HIShape in tk 8.4.16. My new code computes the position by adding the positions of all parent windows, and this appears to work. To see the changes: http://public.kitware.com/cgi-bin/viewcvs.cgi/Rendering/vtkTkRenderWidget.cxx?r1=1.124&r2=1.127 [^] http://public.kitware.com/cgi-bin/viewcvs.cgi/Rendering/vtkTkImageViewerWidget.cxx?r1=1.83&r2=1.86 [^] For some reason, these patches do not work for the Tk 8.5.7 that comes with OS X 10.6. I downloaded the source for Tk 8.5.7, and its Carbon code is nearly identical to that of Tk 8.4.19. However, when I attempt to get a window Id by calling GetWindowFromPort((CGrafPtr)TkMacOSXGetDrawablePort(Tk_WindowId(winPtr)), the return value is always null. There is a chance that the Tk 8.5.7 installed on OS X 10.6 actually uses Cocoa, in contrast to the "official" Tk 8.5.7 source code, since "otool" shows it to be linked to both the Cocoa and Carbon libraries. I also tried to to switch the vtkTkRenderWidget code so that it passes the HIView to this->RenderWindow->SetWindowId(), in order to sync the Tk code with what the VTK Qt code does, but my attempt failed.

(0018869) David Gobbi (developer) 2009-12-14 14:33	The tk 8.5.7 that comes with OS X 10.6 is actually a special "cocoa" version of tk 8.5.7, it isn't the official carbon version. This is good news and bad. Good, because it makes it possible for a cocoa build of VTK to use Tk. Bad, because apple shouldn't be basterdizing official releases of software packages like this. I have done a fix, by making the vtkTkRenderWidget work with vtkCocoaRenderWindow. This required plenty of changes to both classes, and the addition of a vtkCocoaTkUtilities class that provides access to Tk internals that the tk private header files don't provide access to. There are still some outstanding issues. The major issue is that the tcl and python binding code for the widgets in Wrapping/Python/vtk/tk/ and Wrapping/Tcl/vtkinteraction/ perform an update in response to expose and configure events, and for configure events, this causes the application to freeze. I've added a work-around by avoiding the update under cocoa. The other issue, a minor one, is that I avoid the "is newsize the same as oldsize" check for SetSize and SetPosition in vtkCocoaRenderWindow if a vtkTkRenderWidget is connected. I did this because the NSRect for the view wasn't always being set when it had to be. Hopefully I'll be able to fix this soon.

(0019035) David Gobbi (developer) 2010-01-05 14:34	Fixed on 2009-12-14. Now when VTK is built on OS X 10.6, it will build the cocoa vtkTkRenderWidget by default.

Issue History
Date Modified	Username	Field	Change
2009-09-30 11:55	David Gobbi	New Issue
2009-09-30 11:55	David Gobbi	Status	backlog => tabled
2009-09-30 11:55	David Gobbi	Assigned To	=> David Gobbi
2009-10-05 11:42	David Gobbi	Note Added: 0017950
2009-12-14 14:33	David Gobbi	Note Added: 0018869
2010-01-05 14:34	David Gobbi	Note Added: 0019035
2010-01-05 14:34	David Gobbi	Status	tabled => closed
2010-01-05 14:34	David Gobbi	Resolution	open => fixed
2011-06-16 13:11	Zack Galbreath	Category	=> (No Category)

Relationships