This PR adds the one file: src/main/addon/FileSystemAccessAPI.mjs
*Basic support for the File System Access API:
Supplies methods showDirectoryPicker(), showOpenFilePicker(), showSaveFilePicker(); plus the convenience method supported() to test if a browser supports this API.
Useful Information:
The "File System API" is available in Web Workers.
However the "File System Access API" extensions are Not available in Web Workers,
because the extensions must handle user gestures and Web Workers do Not have access to the
UI thread aka main thread. Therefore we must add this support via the Neo main/addon approach,
Supported by Chrome, Edge, Opera, but not and never FireFox:
https://developer.chrome.com/docs/capabilities/web-apis/file-system-access#browser_support
Tested with Neo on Chrome, Opera, Edge.
See: https://wicg.github.io/file-system-access W3C Community File System Access Report
Reason for this support:
Quoting from the above W3C Report:
This API enables developers to build powerful apps that interact with other (non-Web) apps on the user’s device via the device’s file system. Prominent examples of applications where users expect this functionality are IDEs, photo and video editors, text editors, and more.
In particular, "more" includes data input files, user-generated annotated data output files, and user-determined session configuration state files, typical of data science and data analysis applications. For instance, GIS applications. Such "desktop" applications use the local file system extensively, to read and persist user-generated files, and do not merely display data from the cloud.
So this is a minimal addon that provides maximal support for Desktop applications.
It could also serve the purpose of a minimalist first exercise in coding main addons.
What kind of change does this PR introduce? (check at least one)
Does this PR introduce a breaking change? (check one)
If yes, please describe the impact and migration path for existing applications:
The PR fulfills these requirements:
This PR adds the one file: src/main/addon/FileSystemAccessAPI.mjs
*Basic support for the File System Access API:
Supplies methods
showDirectoryPicker(), showOpenFilePicker(), showSaveFilePicker(); plus the convenience methodsupported()to test if a browser supports this API.Useful Information:
The "File System API" is available in Web Workers. However the "File System Access API" extensions are Not available in Web Workers, because the extensions must handle user gestures and Web Workers do Not have access to the UI thread aka main thread. Therefore we must add this support via the Neo main/addon approach,
Supported by Chrome, Edge, Opera, but not and never FireFox: https://developer.chrome.com/docs/capabilities/web-apis/file-system-access#browser_support
Tested with Neo on Chrome, Opera, Edge.
See: https://wicg.github.io/file-system-access W3C Community File System Access Report
Reason for this support:
Quoting from the above W3C Report:
This API enables developers to build powerful apps that interact with other (non-Web) apps on the user’s device via the device’s file system. Prominent examples of applications where users expect this functionality are IDEs, photo and video editors, text editors, and more.
In particular, "more" includes data input files, user-generated annotated data output files, and user-determined session configuration state files, typical of data science and data analysis applications. For instance, GIS applications. Such "desktop" applications use the local file system extensively, to read and persist user-generated files, and do not merely display data from the cloud.
So this is a minimal addon that provides maximal support for Desktop applications. It could also serve the purpose of a minimalist first exercise in coding main addons.
What kind of change does this PR introduce? (check at least one)
Does this PR introduce a breaking change? (check one)
If yes, please describe the impact and migration path for existing applications:
The PR fulfills these requirements:
devbranch, not themainbranch