I like this suggestion now that the widget has an explicit file type selector.

@markotoplak, I've started working on this and I have a few questions related to the current implementation.

• Why is the reader choice not a setting?
• Related to this, the combo goes back to auto-detect when the user chooses a different file. This may be annoying (and unexpected) for somebody who is reading multiple files with non-standard extension. I suppose the combo must not change behind the user's back.
• Why is it disabled for URLs? Is there a deeper reason or is it just because it uses a different code for reading, and implementing manual format selection would require rewriting it.
• If we keep it disabled, why wouldn't we move it below the File option (above the URL)?

The File widget's code is indeed one big mess. (And I confess to not only contributing to it but perhaps even establishing it in the first place.) It could be one's big project to reimplement if from scratch, or, better, based on (and merging it with) the CSV widget.

* Why is the reader choice not a setting?

It is stored as a part of the RecentPath object so it is stored in there.

* Related to this, the combo goes back to auto-detect when the user chooses a different file. This may be annoying (and unexpected) for somebody who is reading multiple files with non-standard extension. I suppose the combo must not change behind the user's back.

I probably stored the reader into RecentPath because changing the file in the selector then also changed the reader. But I do agree with you: choosing a completely new file should in fact use the same reader as is currently selected.

* Why is it disabled for URLs? Is there a deeper reason or is it just because it uses a different code for reading, and implementing manual format selection would require rewriting it.

I did not look into that part at all. In the end, the code uses the same readers but goes through different paths. Or maybe how I implemented the settings into a RecentPath was the problem...