Re: [Jointtrack-devel] Mac OS X Port

[Jonathan M. <me...@un...>]

Hi Shang,

On 10/11/2007, at 3:06 PM, Shang Mu wrote:

> Welcome to the project! You might be senior than any of us in the  
> aspect of software engineering. Feel free to give advices. See my  
> replies to your individual questions below:

LOL!  I doubt it. :-)  I've probably just been tinkering for longer.

> >     - I plan to set up an XCode project to handle the build.  (XCode
> > is the free-as-in-beer IDE that Apple provide as part of OS X.)  Is
> > this OK?
>
> That's OK. Apparently you know Mac much better than us. If that's  
> the proper/most usual way to do it under OS X, just do it. That  
> said, maybe CMake or other cross-platform tool would serve the job  
> better.

The advantage of CMake is that it could be used for Linux builds too  
(and Windoze ;-).  I'm interested in XCode for its ability to act as a  
well-integrated IDE (editing, debugging, profiling, etc.).  However,  
I'll look into CMake since there has apparently been some work done to  
allow it actually to generate XCode projects.

> >     - What is your policy on including OS X headers and libraries  
> for
> > the dependencies (ICE, Boost, VTK, OpenCV) in the JointTrack SVN
> > repository?  Quite a few other projects (e.g. Blender and OsiriX) do
> > this to make things easier on developers.
>
> Not sure what you mean. Add header to the dependencies? Or add  
> headers to JointTrack source files so that those dependencies work  
> fine?

I mean to add both the headers and libraries of each of the  
dependencies.  The idea is to have a working copy of the dependencies  
which are regarded as "current" for the project.  For example, here's  
the Blender lib directory from SVN:
     http://projects.blender.org/plugins/scmsvn/viewcvs.php/trunk/lib/?root=bf-blender
It has compiled versions of each dependency for each platform - just  
headers and libs.

I guess this may not be important until there are more developers, but  
certainly on the Mac platform, getting all of the dependencies  
compiled is a huge pain.  Then people can use different settings when  
they're compiling, which can lead to some bizarre problems.

> >     - Are there any major problems you can foresee with the porting
> > task?
>
> I'm not sure if the following is a problem:
> VTK gave me much more pain than any other library. One particular  
> problem is "wglMakeCurrent() failed" error (which is not entirely  
> vtk's fault). On Windows, an openGL context can only be current to a  
> single thread(i don't know if it's the same case on OS X or linux).  
> vtkRenderWindowInteractor creates a thread by itself. Apparently in  
> JointTrack we need access from other threads for many other tasks  
> like change the display mode or switch to another image. In vtk  
> there seems to be no easy way to let the interactor thread release  
> its OpenGL context, so wglMakeCurrent() fails every time some  
> operation is invoked in another thread. But it does not make much  
> sense to derive a class from vtkRenderWindowInteractor because it  
> actually has platform-specific subclasses called  
> vtkWin32RenderWindowInteractor, etc. To get around the problem, I  
> added vtkRenderWindow::IgnoreMakeCurrentOn/Off(), but inter-thread  
> function call is needed when a redraw of the window is needed: I  
> used SendMessage(WM_PAINT,...). To avoid platform specific call like  
> SendMessage(), the only way I can think of is to indiviually derive  
> classes from vtkWin32RenderWindowInteractor,  
> vtkXRenderWindowInteractor ... in which case things like "#ifdef  
> _WIN32" is still needed.

I think the JTRendererVTK stuff will need a lot of work.  I noticed  
it's probably the most heavily tied to the Windows platform,  
especially as you mention, with all of those Windows messages that are  
being sent.

I'll get back to you about that sometime.  I'll see if I can find out  
how other cross-platform apps are using VTK.  I've been wondering  
whether embedding the VTK window inside a WX window might solve some  
of the message-passing issues.  I haven't had the chance to look at  
any of it in detail yet though.

> Because you joined, we officially begin to use the mailing list at  
> this moment!

I'll upload some patches to the SourceForge Tracker sometime this week  
(hopefully I'll have time).  I have the core bits in the JTMVCModel  
directory compiling nicely, but I've commented out all of the  
filesystem stuff for now (I won't submit commented-out parts in the  
patches!).

Unfortunately, I don't have (easy) access to the MS development tools,  
so probably the best thing is if you guys can check that my patches  
don't break the Windows build before committing them (or eventually I  
can commit them and you can just revert them with a message if they  
cause problems).

Thanks,

Jonathan Merritt.