Hi Volker
On 16/12/13 19:52, Dr. Volker Jaenisch wrote:
At first Jeremys HDF5-import utilizing h5py. Lets call it J_HDF5
https://inqbus-hosting.de/volker/veusz_screen.png/image_view_fullscreen
Second my hdf5 import utilizing pytables. Lets call it V_HDF5
https://inqbus-hosting.de/volker/veusz_screen2.png/image_view_fullscreen
The main difference seems to me that J_HDF5 is not usable for tabular HDF5 data.
On the other hand is V_HDF5 at the moment not capable to deal with
with plain hdf5-data (aka n-dim fields of floats for instance).
It probably won't be hard to support compound data types in my import
filter - I can treat them similarly to groups. I didn't find any example
files which used them, so I haven't bothered so far. I need to make the
code which walks the file understand that the V datatype has different
components.
This work requires many changes on the VEUSZ core but a running prototype is
already available and the existing dialogs are already ported (in an older
VEUSZ version!) to
the new interface architecture. I will support Jeremy wherever I can to bring
this solution upstream.
If you look at the import_improvements branch, you'll see I've split
apart the import codes as suggested by you and your branch. It's very
similar, but I've done it slightly differently without the individual
directories for each data format. I tried this but got tired with the
proliferation of identically named files and imports. There's a
defn_foo.py -containing object definitions,
dialog_foo.py - implementing the import dialog, and
import_foo.ui
I've put the import_foo.ui files in the usual ui/ directory, due to the
earlier module reorganisation - I think it's nice to keep the python
separate here. It also improves by also incorporating the code for the
command line interface in defn_foo.py. Essentially all the import code
is in one place (apart from the capture dialog, which uses some of it).
I think it gets rid of a lot of the imports which were in your branch.
It should be trivial to drop your import plugin into this setup.
A second point has to be considered and this is HDF5 export. The huge graphical
software package "mathlab" has thrown away its proprietary data-format and uses
HDF5instead.
Adopting this strategy to VEUSZ should therefore be possible, also.
But I suspect that there are far more changes at the VEUSZ core needed to
achieve this
than for the HDF5 import with the new interface layer. Also backward
compatibility
issues have to be dealt with and so on. There is lots of discussion needed how
the
structural possibilities HDF5 offers are used best for VEUSZ-Save-Files.
I can see there might be some need for this, but my usual procedure is
to use the link option when loading the data. This means that the data
can be reloaded from the original file, and updates when the original is
updated. The vsz file doesn't store the data itself in this case and is
fast to save/load.
I think your hdf branch doesn't implement the linking (at least I
couldn't find the code), so maybe this would help.
It might be nice to have a combined HDF saved file type (at least
optionally) for the case where you want a single document to be
transported around. As earlier suggested, you could have all the
datasets stored under a special group, with the rest of the document
stored as a variable length string in another dataset. Maybe something like
Veusz (group)
- Datasets (group)
- ds1
- attribute: datatype=1D
- ds2
- attribute: datatype=2D
...
- Document (dataset, string)
Best wishes
Jeremy
_______________________________________________
Veusz-discuss mailing list
Veusz-discuss@gna.org
https://mail.gna.org/listinfo/veusz-discuss
