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

[Dan Mueller]

Hi Jakub,

Unfortunately ManagedITK will never be Mono compatible. ManagedITK
uses "It Just Works" (via C++/CLI) to generate wrappers. This is a
Windows specific mechanism.

Mono requires the wrappers to be generated using P/Invoke. WrapITK
(with pure SWIG) could be extended to generate C# wrappers, but they
would be quite different from the ManagedITK ones (which I think means
no properties, no delegates for events, etc).

Integrating ManagedITK with WrapITK (at least the way I see it) will
not generate C# wrappers for Mono...

Sorry for the bad news.

Regards, Dan

2008/7/8 Jakub Bican <jakub.bican at matfyz.cz>:
> 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
>>
>>
>>
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
>