File format chooser keyed off file extension

[biagas]

We have a huge number of DB plugins, and our current 'open as' option is just a pita to use, especially if the format you want is at the bottom of the list.

I think it would be great to offer a format-chooser that is keyed off the file extension. If a particular extension is used by multiple formats, then we could offer all formats that read that extension as options in the chooser.

May help solve problems with the wrong reader opening the file, espcially for hdf5 based formats.

(Please click check boxes AFTER submitting ticket)

• [ ] High - User productivity significantly improved
• [x] Medium - User productivity partially improved
• [ ] Low - User productivity trivially improved

[markcmiller86]

especially if the format you want is at the bottom of the list.

Not sure if you are aware but hitting a single key will advance to the first occurence of a plugin starting with that letter in the list. So, hitting z key will time-warp you to bottom or near bottom; still a pita but a little less scrolling.

[rusu24edward]

@visit-dav/visit-developers How does Visit know which database to use to read the file when "Guess from file name/extensions" is selected?

[markcmiller86]

In plugin's .xml file, there is a section for <FilePatterns> which indicates which file extensions match the plugin. Example for silo...https://github.com/visit-dav/visit/blob/7e064779b88071e2fb14534b3e2901107f9f22ef/src/databases/Silo/Silo.xml#L12

[rusu24edward]

Thanks for the quick response @markcmiller86! Do you know where in the source code this information is used to actually select the database reader?

[markcmiller86]

That would be in https://github.com/visit-dav/visit/blob/e79fd35289b8e8852d5845c23ee0af48a58de0d1/src/avt/Database/Database/avtDatabaseFactory.C#L347

That said, the logic there is hugely complex to handle a variety of odd-ball situations...

• preferred plugins vs. other plugins ordering
• failed to open vs. opened but nothing appears to be in the file
• strict vs. non-strict matching
• not crashing VisIt due to a poorly coded plugin
• falling back to something when all else fails

[rusu24edward]

Thanks @markcmiller86! After investigating this a bit, I can think of two ways to handle this.

1. Create a local dictionary in the FileServer that maps file extensions to database readers. Use this to quickly update the dropdown menu with the appropriate types. The upside is that it is all done locally and intuitively. The downside is that we would have to keep track of this mapping, so it adds complexity to our workflow. For example, if someone adds a new database plugin, we would have to update the map to correlate that reader with its filetypes.
2. Use <FilePatterns> to map file extensions to database readers. This can be done by communicating with the mdserver and potentially leveraging the logic in avtDatabaseFactory::FileList. This is a complicated process and seems like overkill just to try to guess the right reader for the extension.

[markcmiller86]

Our MOAB collaborators could benefit from this so I am pulling out of the reviewed state. The basic idea is that when a user selects a file in the list of files, the GUI can adjust the list of plugins that show in the Open file as type pull down so that it shows matching plugins first and if there is only a single match, it selects that option too.