[Insight-users] INSIGHT JOURNAL: managedITK (ITK 3.8 ?)

[Jakub Bican]

Hi all,

I am not familiar with the ManagedITK project, but as I am reading the
conversation, I would like to ask if you are considering to keep the
cross-platformity by making it possible to use ManagetITK with Mono:

    http://www.mono-project.com/Main_Page

Regards,

    Jakub


2008/7/8, Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr>:
>
>  Le 7 juil. 08 à 22:15, Gaëtan Lehmann a écrit :
>
>
> >
> >
> > >
> > > Is there material that can be merged/shared with the other
> > > wrappings ?
> > >
> >
> > Dan,
> >
> > I wanted to ask you the same question — Luis did it first :-)
> >
> > Despite you said that WrapITK is a "totally separate project", ManagedITK
> has reused lot of code from WrapITK. Actually, they still share a lot of
> code — a quick look at  managed_itkCastImageFilter.cmake,
> from ManagedITK, and wrap_itkCastImageFilter.cmake would be quite
> convincing: they even share the comments :-)
> > They are not all as similar of course, so the question is:
> >
> >  Would it be possible to avoid the current code duplication?
> >
> > The reason why I wanted to ask that question now, is because WrapITK has
> made great progress in the last weeks. Some times ago, I began to work on a
> pure swig implementation of WrapITK. The work was left unchanged for a quite
> long time, but recently, Ali decided to work on the java part. His work
> convinced me to work again on python part. At this time, wrapitk unstable is
> nearly completed in python — I already began to use it for real image
> analysis task, to benefit of the numerous improvements — and Ali is using
> java part on his side. The code is available at:
> >
> >  http://code.google.com/p/wrapitk/source
> >
> > In WrapITK unstable, I took care to completely separe the type
> declarations — in the wrap_*.cmake — and the language specific code. The
> goal is to make all that hard job of defining template parameters for type
> instantiation fully reusable for something else than wrapping with cableswig
> or swig. The examples I had in mind were:
> > * wrapping python with PyBoost
> > * ExplicitITK
> > * ManagedITK
> >
> > If you agree, I would be pleased to try to see with you a way to merge
> ManagedITK and WrapITK.
> >
>
>
>  After a bit of reading of ManagedITK code, I'm quite convinced that there
> is some factorizing to do, and that it would benefit to both projects.
>  The big differences I see are:
>  * the code generator, of course very specific of ManagedITK
>  * the Common directory, which is specific of ManagedITK
>  * the wrapped types — some types available in WrapITK are not in ManagedITK
> (complex types for example) and some in ManagedITK are not in WrapITK (RGBA
> for example). It would be nice for both to have them :-)
>  * the modules names
>  * the managed property definitions
>  * the underscore before the template parameters in the instantiated name
>  * the external projects implementation
>
>  Specific code is quite well separated, and some of the code specific of one
> project would benefit to the other.
>  The only specific code mixed with generic code at this time is the managed
> property definitions. I do think they can be quite nicely moved outside the
> generic files, in the /Languages/Managed/Properties/ for example (to reuse
> the wrapitk directory layout). Then, when END_WRAP_CLASS() is called in the
> /Modules/*/wrap_*.cmake files, the content of corresponding managed_*.cmake
> file can be read (if it exists), to define the properties for the current
> classes.
>  That way, all generic code can be common to both projects, and specific
> code is localized in a single subdirectory of the /Languages directory.
>
>  The module names may be a problem depending on their importance in
> ManagedITK.
>
>  The rest looks much like details — underscore in name can be used in
> wrapitk or can be manageditk specific without problem, and external project
> shouldn't be that difficult to implement in one way or the other.
>
>  Do you think this kind of organization for managed properties would fit
> your needs?
>  There are surely many other problems — I hope they are not too difficult
> :-)
>
>
>  Regards,
>
>  Gaëtan
>
>
>  --
>  Gaëtan Lehmann
>  Biologie du Développement et de la Reproduction
>  INRA de Jouy-en-Josas (France)
>  tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
>  http://voxel.jouy.inra.fr  http://www.mandriva.org
>  http://www.itk.org  http://www.clavier-dvorak.org
>
>
> _______________________________________________
>  Insight-users mailing list
>  Insight-users at itk.org
>  http://www.itk.org/mailman/listinfo/insight-users
>
>
>