Please add a "save as" / "new file" dialog

[jonmountjoy]

Hello!

Would it be possible to extend the native dialogs to handle the "Save As" action. It's similar to the directory selection that's already there, but provides a text field for the file name, as shown below for MacOS:

This could be an entirely new API method I guess, or perhaps extend FileType with a saveoption, and allow something like:

FilePickerResult? result = await FilePicker.platform.pickFiles(type: FileType.save);

Thanks!

[miguelpruivo]

@philenius could it be done?

[philenius]

@miguelpruivo yes, I already have a working implementation for a save-as dialog on Windows, Linux, and macOS. The current implementation (in my old Dart package) offers a separate method

final String? selectedFileName = await saveFile(
    defaultFileName: 'default-file.txt',
);

. I could easily adapt it to return FilePickerResult. Can you provide an implementation for Android and iOS or don't you plan to support this on mobile devices?

[miguelpruivo]

I believe that picking directories is enough and serves the same purpose on mobile.

[philenius]

@miguelpruivo could you please resend the invitation for your repository so that I can contribute? Sorry to bother you again. The original invitation has expired because I was on vacation in the meantime. Thank you.

Concerning this issue:
Because you're not planning to implement a separate save-file-dialog for Android and iOS I would suggest two different approaches:

1. @jonmountjoy proposed to add an additional FileType, e.g. FileType.save. I don't think that this is a good idea because the save-file-dialog allows to set a file type filter. If we were to use FileType.save for showing a save-file-dialog, then we couldn't set a file type filter at the same time. The following screenshot shows the save-file-dialog on Ubuntu where the file type filter is set to filter for image files:
   

2. I would prefer to add an additional, boolean parameter to FilePicker.platform.pickFiles(), e.g. saveFileDialog. This parameter would only have an effect on desktop platforms (no effect on iOS/Android).

Unfortunately, we'll need one more additional parameter to set the default file name (the save-file-dialog includes a title, a file type filter, and a default file name).

So, the final API could look like this:

Future<FilePickerResult?> pickFiles({
    String? dialogTitle,
    FileType type = FileType.any,
    List<String>? allowedExtensions,
    Function(FilePickerStatus)? onFileLoading,
    bool allowCompression = true,
    bool allowMultiple = false,
    bool withData = false,
    bool withReadStream = false,
    // NEW:
    bool saveFileDialog = false,
    // ALSO NEW:
    String? defaultFileName,
  }) async { ... }

Knowing that we'll need two additional parameters, do you still want to integrate the save-file-dialog in the existing function pickFiles()?

[miguelpruivo]

@philenius I'm afraid this could confuse IO users with even more parameters, however, if it's handy for some, I don't see a reason why we shouldn't add it as well.

I'm trying to understand what is this feature about — it's just to pick a location without picking the files? If so, the best approach would be adding a desktop implementation only for saving the files with a new method, something like FilePicker.instance.saveAs({String? fileName}). That implementation would throw an UnimplementedError in the other platforms and would work only in desktop. Looks like the most reliable way to me. What do you think?

[philenius]

@miguelpruivo, exactly, that was my thought, too. Too many parameters can become confusing.

You go the idea right. A save-file dialog allows the user to select an output file. In the example of a tool for creating PDF files: the user can select the path and name of the output file (either an existing file or a new file) to which the program will write/export the PDF file. The return value of the save-file dialog is only the path to the file.

I like your idea of providing

FilePicker.instance.saveAs({
    String? dialogTitle,
    String? fileName,
    FileType type = FileType.any,
    List<String>? allowedExtensions
})

for desktop platforms and throwing an exception on mobile platforms. If you add me as a contributor, then I'd love to do the implementation.

[miguelpruivo]

@philenius are the file type and extensions required for that as well? Sure I’ll add you right away.

[philenius]

@miguelpruivo: the decision is up to you whether file type and extensions can be configured, too. At least it has an effect on Windows and Linux:

1.Allow any file types: test.dart is shown

Ubuntu	Windows

2. Allow only image files: test.dart is hidden

Ubuntu	Windows

On macOS, I wasn't able to filter by file type. Although, the dialog in @jonmountjoy 's screenshot (first message in this issue) shows a dropdown for setting the allowed file types.

[jonmountjoy]

I much prefer the proposed direction of creating a new API method as you're doing in #799 (comment) , than my original proposal.

👍

[miguelpruivo]

@philenius already invited you. Yes, looks like a good approach, you're good to go.