VisIt 2.0 changes for plugin developers
Some notes of things to be aware of concerning new internal structures, features, and other changes requiring users with plugins not in the VisIt source code repository to update their plugins before they will build with version 2.0. (Ones in the repository will already have received these changes.)
 Database Plugins XML File Changes
- <Extensions> and <Filenames> have gone away; both been subsumed by a new tag called <FilePatterns>. The FilePatterns tag contains whole-filename globs instead of simple partial extensions or simple non-wildcard filenames.
- As the contents of what was formerly <Extensions> have become globs, they should now typically be prefixed with a "*.". For example, "vtk" in the old Extensions tag becomes "*.vtk" in the new FilePatterns tag.
- What was formerly <Filenames> have also become globs, but because these were already intended to be whole-string matches, these will likely not change when moving to the FilePatterns tag. For example, "MyHeaderFile" in a Filenames tag will remain "MyHeaderFile" in a FilePatterns tag.
- There should only be one FilePatterns tag; plugins which used to have both Extensions and Filenames will need to combine these two new FilePatterns sections within a single tag.
- The "specifiedFilenames" attribute for the Plugin tag was never used and should be removed. There are some similarities with its intended use and the meaning of the "filePatternsStrict" attribute, though. (See below.)
- There is a new "filePatternsStrict" boolean attribute on the Plugin tag. This is to indicate that the a file whose name does not match one of the FilePatterns will simply not open that file. Sometimes this is because the plugin needs to do operations based on the opened file's filename, e.g. changing an extension to find a complementary file, like foo.header implies the existence of foo.data. It can also be used in the case where you are fairly certain a user won't modify the file pattern, such as a code specific file format which does not allow the user to use a different file extension when writing the data. Note that we intend to allow the user to override this strictness with "Open As", with the caveat that the former case is likely to still fail.
- (Planned but not implemented yet as of Dec 29 2009) A new feature, "opensWholeDirectory", will exist to allow plugins to be handed an entire directory instead of a single file. This is a new capability, but might be a good fit for existing plugins.