Some required features of new version package
Status: Beta
Brought to you by:
adolgert
Menu
▾
▴
Hi, Andrew
I'm really happy to this control and I sucessfully used this control for real word application.
Here is some requested features of next version control packaging.
At first, current distribution(VTK-5.0.1-control-1.1) have Managed C++ prj and C# sample prj in one solution.
So how about split separate solutions of c++, c# examples instead of current one solution contains c++, c# ?.
I had been used C++ about more than 10 years, but I have no idea about Managed C++. I jump to C# directly because I need some convient and nice GUI development environmet.
So, my main interest is only using this control, not compile vtkContol managed c++ source.
I think the situation is similar to almost everyone using C#, VB, etc. And incorrect setting of path in current deployed file make it hard to use this wonderful control.
Second, We need some documentation about using and compiling source etc in the distrubuted packging.
Thrid, If seperate c# or vb example codes are depolyed, it is better that the codes be executed without installation (e.q. PATH setting)
This can be done by copying required dlls to some folder and making target exe ouput folder to same floder. Yes this is redundancy but first impressoin is very important to users.
Fouth, Managed C++ distribution, prject file paths are not relative but almost absolute.
ex:) <AssemblyReference
RelativePath="..\..\..\..\..\Program Files\VTK\bin\vtkCommonDotNet.dll"
AssemblyName="vtkCommonDotNet, Version=0.0.0.0, processorArchitecture=x86"
/>
Fifth, source code compile
Current version use Cmake and some vb macros. I tried but this is very complicated to me, so I gave up source code complation.
Is there any possiblity to compile more easily?
For example, msbuild or nant system.
I had e-mailed tutorial to you.
-----------------------------------------------------------
lotus
First, thank you for the tutorial. That's great. I know Latex but haven't used Lyx. No problem, though.
Splitting the examples into C# and Managed C++ seems like a good idea. I neglect VB mostly out of distaste, which is a dumb reason. I'd be happy to include VB examples.
I am keenly aware that my packaging makes installation unclear and that there should be more documentation included in the packaging.
I don't think I can afford to put the Dlls in multiple places during installation, partially because it would confuse people when there is a new version. The best solution, to my mind, is to install the dlls as assemblies, which means putting them into the GAC. The net result is that executables can always find their dlls without needing the path.
Fixing the absolute project paths requires working out where to put the samples in relation to the installation directory. Fine. We can work that out in one go. How about:
C:\Program Files\VTK.NET 5.0.1\bin
\src
\samples
or something like that? Because a lot of people also have VTK in the path, this causes trouble, but I don't know any way around it, aside from using the GAC (Global Assembly Cache).
The biggest one: compilation is tough. I'm impressed that someone other than me figured it out, really. Remember that my goal is to make this wrapper part of the VTK wrappers. Switching to MSBuilt or Nant would mean recapitulating the normal VTK build system, which would be a large piece of redundant work. The one problem with the normal VTK build and CMake is that it will not create Managed C++ projects. All that the VB macros do is convert the VTK .NET projects to managed C++. The solution is to give CMake the ability to create Managed C++ projects. That is also on my todo list.
Drew
My group is currently in the process of porting our visually intensive (obviously) program from an MFC app to a C# application. I have done some prototyping with your vtk wrapper code and everything seems to work with our setup. Many Thanks.
I do have a question about the wrapping technique used. Was any consideration given to using SWIG? This technology is working very well for our own C++ to .Net interfaces and also seems to be what the VTK-Ruby project used.
Maybe this is another thread.
I've used SWIG and like it for wrapping my own projects. VTK has its own wrapper generator and is particularly tuned to it, meaning that the header files have structure particularly for it and special #ifdefs. VTK uses its own generator to make Tcl, Perl, Python, and Java wrappers. I thought the Ruby wrapper was done the same way, but you suggest not.
People sometimes write the VTK mailing list about using SWIG, but I didn't know of anyone who completed the custom typemaps to use VTK with SWIG, except now the Ruby fellow. I think using SWIG with VTK would make much of the custom hints in the header files unavailable.
I went with VTK's own generator because it works well for the other wrappers and because using their generator offers a chance to fold this wrapper in with the rest of them. It has worked pretty well for this project. I want to play nicely so that I can play the Open Source game. I'm not after anything more than increasing available functionality, and doing things my own way seems counterproductive.
The Kitware group seems to be involved in writing a newer style of wrapper generator, not currently applied to VTK. Maybe that's the future for VTK's wrappers.
Drew
Thanks for the reply, obviously you have considered SWIG.
Personally I have not used the vtk ruby binding and do not know how much functionality is included in the binding but it seems to integrate into the cmake suite after the patch is applied to the vtk code.
In case you would find the Ruby project of interest the address is here: http://www.gfd-dennou.org/arch/ruby/products/ruby-vtk/
OK. Thanks for the link. I haven't looked at the Ruby patch. - Drew