Proper implementation for FileNameOption/FileNameOptionStorage
It should be thought about which features of the old implementation in filenm.c is appropriate for new analysis tools, and those should be implemented in the mentioned classes. It should also be possible to wrap the old code in the new classes, but the interface presented by FileNameOption still has to be thought out carefully. At least the interface should be implemented soon, even if all the internal details are not, to allow development of actual tools without having to worry about the need to change them later to adapt to changes in this interface.
Make default option values more flexible.
Added a new method that only provides default values for options that
are set, but for which no value is provided. This makes it possible to
conveniently use file name options like they used to work in the old
tools, namely that '-ox' without a file name would turn on the output
for a certain feature using the default file name. The implementation
now supports the same functionality for all types of options.
Extension completion for FileNameOption.
- Make FileNameOption to complete extensions for input files, like the
old file options did.
- Add descriptions for all file name options to improve the help output.
- Make defaultValueIfSet() really appear in the help output: it worked
only in the case the option value was not stored.
- Adjust the reference for command-line help tests to match the new
Part of #642.
Fine-tuning for FileNameOption.
- Change behavior of required options with default values such that the
default value is now used without an error if the option is not
provided. This is how it used to work with file name options. For
most other cases, this combination doesn't make much sense, but
changed it such that it works consistently for all cases.
- Add FileNameOption::defaultBasename() as a more intuitive interface
for providing a default for file name options. The name makes it
clear that no extension is expected, and the option also transparently
treats required/optional arguments without the user needing to
understand the difference between defaultValue() and
Closes #642; there is still some things to be improved, but should now
provide about the same features and about the same input options as
the old t_filenm-based system.
Use filenm.c data for FileNameOption.
Expose the necessary data (through functions) from filenm.c so that
FileNameOption can use it. Removes the need to duplicate the file name
extensions (potentially also other stuff in the future) for the period
that both coexist.
Part of #642.
Make FileNameOption behave more like old filenm parser
If a required file name option is provided without a value, then it is a
no-op. Previously, FileNameOption raised an exception for such usage.
Add a test to cover this case.
Related to #642.
#1 Updated by Teemu Murtola about 9 years ago
- Priority changed from High to Normal
- Completion of default extensions for file names that don't refer to existing files. Here, I think the old functionality should be revised such that if the user provides a file name that refers to an existing file, it should be used as it is, no matter what it's extension is. Usually, the user knows best what he wants to do...
- Task #666 includes improvements to printing the option summary for the file name options; it can require some adaptation in the actual option implementation as well.
Depending on what other functionality related to file names there is to refactor, it could be clearer to move the file name option stuff to a separate module together with other functionality related to file names.
Now the programming interface of the file name options should provide the major functionality needed in tools, so reducing the priority and removing the dependency to the porting task #665.
#5 Updated by Teemu Murtola almost 6 years ago
- Project changed from Next-generation analysis tools to GROMACS
- Category set to core library
- Status changed from In Progress to Closed
Some internal implementation is still necessary to make it behave exactly like the old system, but closing this issue as the interface is reasonable already. New file types can also be added when needed.