Hi Daniel,
I try to comment inline below as good as my memory serves me. Take it
with a grain of salt though, since I haven't worked with that code for
quite a while.
Best,
Sascha
Hi,
I just encountered an unfortunate detail in using file readers derived
from mitk::AbstractFileIO directly. I cannot use QmitkIOUtil because I
want to read from a Qt resource and (Qmitk/mitk::)IOUtil verifies
_file_ existence before looking for readers (and finds that my Qt
resource is not a regular file). Due to AbstractFileIO's double
inheritance we need to write code like below to specify an input file
| MySpecialFileIO_C reader;|
| reader.mitk::AbstractFileReader::SetInput(":/in_exe/my.file");|
| auto result = reader.Read();|
This is a little strange indeed. The way it was designed is to use the
IFileReader and IFileWriter interfaces, and not work with the
AbstractFileIO directly (except when implementing a reader / writer
pair). So in that sense, it would be more idiomatic to get a IFileReader
first and then work with that:
MySpecialFileIO_C special_io;
mitk::IFileReader& reader = special_io;
reader.SetInput(...);
This way, no ambiguity exists.
AbstractFileReader::SetInput is specified explicitly because
AbstractFileIO also inherits AbstractFileWriter::SetInput and the
compilerwants a clarification of what we want to call.
* was the name of SetInput used in two base classes on purpose? Why
not avoid name collissions by different names, e.g.
SetInputLocation() and SetInputData()?
The same name was chosen for "consistency". Sure, this can be argued
about. The ambiguity only appears when working with AbstractFileIO
directly, which is constrained to the IO system implementation if a user
accesses the system via the interfaces only.
* would you mind removing the _file_ existance check from IOUtil
(more specifically, from mitk::FileReaderSelector's constructor)?
Or could this check be made aware of Qt's resource system?
o I know that the first option would require each reader to
handle non-existing files. But this should be a basic check
done in every reader anyway, right?
As far as I remember, this was exactly not the case. I think there were
some ITK or VTK readers, which didn't check this but failed
spectacularly instead. Maybe this has changed.
The interfaces contain SetInput() overloads which take a std::istream
object as input. In case of Qt resources, I believe this is the way to
go (with the current state of the system). Especially, since you seem to
know exactly what reader you want already. Now, you only need a way to
create a std::istream from a Qt resource. Not sure if this is straight
forward or not. If not, you could embed the file using the
CppMicroServices resources system which provides convenient classes to
easily create a std::istream from an embedded resource. Again, I am not
sure if this an option for you at all.
(Q)mitk(::)IOUtil is definitely lacking support for input streams. Also,
the mitk::FileReaderSelector could probably be made more flexible such
that it continues to try and match file reader services based on the
mime type of a non-existing path passed in (then only relying on the
file ending).
I hope this helps.