Fwd: [OctDev] savevtk

[Levente Torok]

---------- Forwarded message ----------
From: Levente Torok <address@hidden>
Date: Tue, Nov 16, 2010 at 10:13 AM
Subject: Re: [OctDev] savevtk
To: "c." <address@hidden>


On Mon, Nov 15, 2010 at 11:55 PM, c. <address@hidden> wrote:
> Philip,
>
> On 15 Nov 2010, at 21:09, Philip Nienhuis wrote:
>
>> Oh I didn't know. Thank you for this info.
>> I suppose Levente and I just followed Martin Helm's suggestion (in the 
>> maintainers-octave ML) to put them in IO.
>> Googling around for vtk I got the impression that vtk is more related to 
>> graphics output than just plain file I/O but then again not so closely as to 
>> put the scripts in the plot pkg.
>>
>> So, if there's already a better home for <whatever>vtk in the fpl pkg I 
>> think it's a good idea to put them there.
>>
>> I'll wipe them from io svn (I uploaded them just yesterday).
>
> I didn't mean to say you should remove them, maybe io IS the right place for 
> functions that write vtk files?
> what I meant is that, given that we have many different functions that save 
> to different vtk file formats, maybe we should
> chose one single package where they all can be put together.
>
> I see different possible solutions and would be interested in hearing 
> somments from others
>
> solution 1)
> putting all vtk-file related functions in fpl which is a package meant to be 
> used for allowing data visualization with external programs
>
> solution 2)
> as many functions to output in third party file formats are in 'io' maybe the 
> vtk functions should also go there
>
> solution 3)
> 'fpl' is composed of 3 different sets of functions:
> [a] functions to output data in external file formats (.vtu and .dx)
> [b] wrappers for controlling opendx visualization from within octave
> [c] wrappers that produce plots in octave's own plotting system with a syntax 
> compatible to matlab's pde-toolbox (pdeplot, pdemesh)
> so maybe we could get rid of 'fpl' by moving [a] into 'io' removing [b] (as 
> opendx is now obsolete and unmaintained) and moving [c] into 'bim' which is a 
> package similar to pdetool
>
>
>> Nevertheless, I think (some/most/all of) my remarks about style and error 
>> catching still hold (especially error catching as unwary users may have 
>> undue trouble figuring out exactly what went wrong when errors occur).
>
> I also think your comments did make sense
>
>> Philip
> c.

>From the description of the packages I have the concept.
All graphics related file saving stuff should go into fpl.
If something is not graphical but saving/loading, then it should go to io.
Personally me, I don't see the usefulness of developing very active
interaction/controlling capabilities for different external programs
such as opendx.
>From the descr bim and pdetool packages seem to serve completely
different purposes.
Sorry for being late in doing some corrections.
Lev