Save images directly to native file system

Motivation

With the Native File System API (now implemented in Chromium-based browsers), it is possible to open and save files directly to the native file system. This would allow SVG-edit to have a much better edit-save cycle, like any desktop editor.

Current behavior

Clicking SVG-edit > Save Image results in a file called “icon (x).svg” downloaded to my computer. Clicking it again results in a file called “icon (x+1).svg” being downloaded to my computer.

Desired behavior

Clicking SVG-edit > Save Image should result in the file that I opened natively to be saved to my file system. Note that for files not originally opened from the native file system, you will have to ask the user where they would like to save the file.

Steps to implement:

1. Start using await window.showOpenFilePicker() if it’s supported by the browser, instead of the standard mechanism. Remember the file handle.

2. On saving, if a file handle exists, for this image, then upon Save, attempt to create a writable stream from it:

        const writableStream = await fileHandle.createWritable();
        writableStream.write(someArrayBuffer);
        writableStream.close();

On first save, this will ask the user for permissions for the browser to save the file. Subsequent saves in that session will work just like any other editor.

[jfhenon]

@codedread I did a quick test in the branch https://github.com/SVG-Edit/svgedit/tree/test-native-file-api This is working very well. Things to watch:

• When you refresh the page, the filehandle is lost (needs to be saved)
• We need a “save as…” option to be consistent
• Safari does not support this API for now (but we could use https://github.com/GoogleChromeLabs/browser-fs-access that proposes a fallback when the API is not supported).

Thank you for the suggestion. I wish to include this in V7 definitely.

[jfhenon]

We will look into the native file system approach in V7. I think we will make it our standard approach and keep the old way as a plugin to be used for old browsers. However, I want also to test out the GoogleChromeLabs/browser-fs-access library if this helps to include Safari in the supported browsers. More and more, we will use modern approach in svgedit that may limit old browser support but offer a much better user experience. Obviously, we will keep older version of svgedit available for old browsers.