Whenever there is more than one reader that ParaView thinks can support an particular file extension, ParaView pops up a Select Reader dialog. There are some pedantic exceptions to this rule, but let’s ignore those for this discussion. This has been a pain for our automated testing. Certain build configurations cause mutliple readers to be available for certain file extensions and then suddenly tests start failing for those builds since the application blocks on Select Reader dialog. Further, we are now facing an increasing trend of readers supporting same extension. For example both IossReader and ExodusIIReader support reading Exodus files in 5.9. In 5.10, same will happen with CGNS, IossReader will support reading conforming CGNS files too.
I am wondering instead of the Select Reader approach to dealing with cases where multiple readers are possible, we need a something more sophisticated.
How about adding a new Open With … menu option similar to Open …. When chosen, the user is shown the Select Reader dialog. The default Open … will directly pick the highest priority reader that supports the extension. Now, we can come up with ways of determing reader priority, maybe even make it user configuration via settings.
I don’t think that Open With is very user friendly. The Select Reader approach at least tries to narrow down the list of readers when possible. I wouldn’t change the current behavior to fix a test issue. Rather I would have one test that tests that dialog consistently and then have a testing feature that bypasses that dialog for everything else.
Should a reader have a priority, or just default for a given extension? It seems having a default could be enough. This could be capture in a config file. Also having some option to pass such configuration at runtime could be nice in the cmd line. Thinking that some group of users could share their reader mapping file config on their pvserver run script.
This will be a game changer for pvw, even if we did already implement something along those lines to solve the pop-up dialog issue.
Maybe in the open dialog directly we could have the info (Drop down) on which reader is picked based on file extension and even have a drop down in place for selecting another one than the default that has been picked? Unless you don’t want a custom dialog. But I feel we already plan to have one for dealing with local/remote files. So maybe all of it could live right there… With also some option to update the defaults right there.
Of course that second point only works if reader resolution is only based on filename… What happen with readers that expect a directory and inspect the content to figure out the proper reader to use?
This will be a test recording hazard. If priorities change (or are recorded with a non-default setup), the selected reader can change.
I think the tests poking some internal mechanism with a filepath and a reader name is probably far better. I don’t know how easy it would be to make the recording mechanism do this or whether it’d have to be a post-processing step. Basically, most tests shouldn’t even have to view the Open dialog at all; they know what they’re looking for. Tests for the Open dialog itself can continue to do what is currently being done.
I know we have some tests which appear/disappear based on whether VisItBridge is enabled because it interferes with the I/O UI path in this way. Being able just have one set of tests for this would be great.
this does not work. For example, there’s only 1 CSV reader in default ParaView. All tests were recorded that way. Now with GDAL/PDAL enabled in a build, there are 3 CSV readers. How can an XML action support this except for having different tests for whether GDAL/PDAL is enabled or not?
Select Reader has not been a fan favorite. We always hear complaints how about to avoid that dialog. @wascott, won’t you agree?
Not at all, how is this different from a default setting and letting user override settings?
In any case, let’s table this. We’re just going to disable GDAL/PDAL on that dashboard for now. For CGNS, soon we’ll always have popup dialog to pick which reader to use since we’ll just have 2 readers that supports the file format.
sure, but this get much more involved than how our current testing infrastructure for recording and playback works. The dialog doesn’t choose the reader…the code after the dialog is closed does. So if you can figure out how to implement your proposal, +1.
Man, I look away for a few minutes, and discussions explode.
With regards to testing, obviously I don’t have many thoughts.
With regards to current behavior with the Select Reader function, the current functionality sucks big-time. Even more than being user friendly, users need to be able to do their job. The issue arises whenever we have a dataset that ParaView “thinks” isn’t a (fill in the blank reader), and offers a list of proposed readers, none of which is correct. The correct reader is then hidden. Users can’t read their datasets, at least without renaming them. This issue appears a few times a year.
I actually like Utkarsh’s idea. Everyone knows what “Open With” means.
If I were king, I would have Open use ParaView’s selected favorite and suggested reader. If there are two or three readers, offer the user a choice of selected readers. If that doesn’t work (wrong reader, or ParaView doesn’t know what to do and needs help), have user use Open With. Inside here, possibly make suggestions (bold some readers, such as CGNS or .csv readers). But, allow ALL readers to be displayed.
I’m not a big fan of the Open With... feature. As is mentioned before, I don’t like the idea of having to scroll through 50-100 readers to find the one I really want. I personally would never use that unless I absolutely had to, and I expect most others are the same. But then, maybe this would be a fallback for users with a misbehaving reader (or have chosen to disrespect naming conventions).
I’m also not a fan of the idea of the regular Open dialog deciding the “best” reader to use automatically. That just seems way too fragile to me and too hard to correct when it does fail. As much of a pain that the select reader dialog seems to me, these two solutions sound worse from a user’s perspective. A better thing to focus on would be improving the CanOpen functions to actually figure out whether a reader can open a file. If readers were better at identifying files they shouldn’t open, then the dialog would pop up less frequently.
I like the idea of augmenting the Select Reader dialog with, say, an advanced button that toggles between the expected readers and a full list of readers in case the right one is not listed.
I’ll note that part of what started this is that our testing infrastructure currently cannot handle both the “there’s one and only one reader” and “there are multiple readers, please select one” cases. When the “only one” and “more than one” changes based on configure flags “far away” from the testing code, things just keep getting out of sync. If testing could just always use Open With… to get consistent behavior regardless of the pool of eligible readers in any given build, it’d just be way more reliable. Given the way testing works, it’s going to have to have some way to go through the UI to select these things (unless my prior suggestion is suitable).
You nail the issue on the head. The Open dialog works perfectly, except when it doesn’t. When it doesn’t, users currently have no way to try to open their dataset with the correct reader. An example is sometimes the Exodus reader will disappear, and users can’t get open their data with it…
Users will never use the Open With dialog. Until it’s the only thing that would work…
Of course we want the Open dialog to chose the “best” reader. Exodus should open with the Exodus reader, Spy data should open with the CTH Spyplot reader. Don’t offer a list of options - unless that is needed (i.e., Open With). For readers that have two options, such as Exodus and IOSS, just offer those two readers (unless using the Open With).
I do agree that as we find issues, we should correct the Open to use the correct reader. But, when it’s the user’s error in file naming (or headers - I don’t know), lets let them try using what they know the dataset is.
With regards to what Ben said, Open With will also stabalize and make predictable testing. Sounds good…
I thought I quickly share my thoughts on this topic. This is a users and developer perspective from outside Kitware.
We have file type extensions in in-house simulation tools, for which we have custom readers. We wrote a little PV QT GUI that shows all available readers in a table with checkboxes and let users turn off all readers that they do not use for their work and which have the same file extensions as some general PV reader. So the user is left with just his favorite reader and can load his files without ever seeing a popup.
The User story would be: Double click a file (or file series) with custom file extension in the Open Dialog and do not see a popup, as all other readers are of less priority or disabled. Let the user decide once, which readers are preferred/activated and store the choice in the config files. Ideally, we developers can supply a pre-defined site-settings.json file so that our in-house readers are preferred, but the user can still overrule it later. And the solution should work for readers added in user plugins, which are not kow at ParaView compilation time.
I can’t comment on how to implement that, but it would be nice, if we could remove our own custom solution to this problem (We implemented this with a custom MainWindows and rewrote the pqLoadDataReaction so that it uses our filtered list of readers.).