NewFileOpen needs file path information in the callback

[rasteric]

Checklist

• I have searched the issue tracker for open issues that relate to the same feature, before opening a new one.
• This issue only relates to a single feature. I will open new issues for any other features.

Is your feature request related to a problem?

You cannot easily get the file path in the callback of NewFileOpen. That's a huge problem because for many operations you need to check certain file properties before accepting a file for being opened. My use case is the user opening an avatar image file that is not allowed to be larger than 4 MB. Right now, I cannot prevent a user from opening a 20GB image file that potentially crashes the machine.

Is it possible to construct a solution with the existing API?

Partly. URIReadCloser has an URI(), from which the filepath can be extracted and the input stream can be closed. However, at that time the file has already been opened, so the interaction can only be: User opens file, an error is displayed. That's not a good GUI flow.

It is not possible to create the desired GUI interaction: User selects file, explanation why file cannot be chosen is shown, Open is blocked.

Describe the solution you'd like to see.

Add a FileValidator that gets a filepath as argument and returns an error. If it returns an error, the error is displayed in the filename field of the dialog and the Open/Confirm button is disabled. As opposed to filters, FileValidators allow the display of the file but may block opening it. FileValidators could have a general enough API to be usable in other places, for example whenever a file is to be probed for having the right format before actually reading it.

Note that a filter before display is not desirable for such use cases. It would be very confusing to the user to not being able to see e.g. a "jpg" file without any further explanation when they know it exists. They'd consider this a bug.

[andydotxyz]

The "opening" of a file does not commit you reading the file so you can close it immediately and error instead of reading the content.

Reading the file content for every item in a folder to decide if it is openable would be very slow for a large folder.

The solution you describe as not a good GUI flow is essentially what most apps and all web clients do to my knowledge.

[rasteric]

I'm not suggesting to open every file in a directory, I'm suggesting to give the programmer to option to open the file the user selects in the FileOpen dialog and enable or disable the Open/Confirm button based on a check.

A good application does not open a file and then show an error message "Sorry, the file is too large, please try again" when it can check this before the file is opened by the user. It's common sense and basic UX design to avoid modal errors like this.

[dweymouth]

I'm not suggesting to open every file in a directory, I'm suggesting to give the programmer to option to open the file the user selects in the FileOpen dialog and enable or disable the Open/Confirm button based on a check.

A good application does not open a file and then show an error message "Sorry, the file is too large, please try again" when it can check this before the file is opened by the user. It's common sense and basic UX design to avoid modal errors like this.

I am inclined to agree with you that what you're describing is the better UX, but I still don't know of any existing apps that use this pattern. If you can point to an existing app like this, especially one that uses the native Windows/Mac file dialogs (e.g. show that it is possible to do this with the "native" UIs) that would be more evidence supporting a build-out of this feature