Repository: microsoft/WindowsAppSDK

Issue #8: Improved StorageFile APIs
Created: 2020-05-18T21:10:03Z
Proposal: Improved file-access APIs for UWP and AppContainer
Summary
Provide an updated version of StorageFile that fixes performance and usability issues in the current Windows.Storage.Storage* set of types.  Support apps that think in terms of file paths & handles instead of StorageFile objects.
Rationale
The current Windows.Storage.Storage* types are designed to give programmatic access to regular files, shell namespace items, and other Windows entities backed by files. A single abstraction over all those spaces is interesting but comes with high costs - namely performance and impedence-mismatch with existing application code.  Project Reunion should clearly explain why StorageFile is important and - where possible - provide lower-level access to the user's files.

The BroadFileAccess capability is "scary" to customers but required even for limited UWP scenarios.
Many libraries and helpers take file paths instead of objects (even instead of handles)
Apps observe serious performance costs related to using StorageFile's built in functionality
Low-level code can access the ...FromApp API variants, but higher-level code (JS, C#) interop for them is very limited.

Scope




Capability
Priority




App has direct access to any files the user has given it using low-level APIs
Must


Feature exposes an object-oriented view of ...FromApp platform APIs
Must


APIs in this feature are synchronous after user permission is acquired
Must


Feature provides standard IStream/ISequentialStream APIs for these files
Should


App can convert between existing W.S.Storage* and types in this functionality
Should


UWPs can access Shell Namespace types directly with user approval
Should


APIs taking or returning StorageFile should return/accept these objects instead
Should


App can prompt the user for broader access without requiring an app restart
Could


App can access user data without user intervention
Won't



Open Questions
Should UWPs be given access to the IShell* family of APIs?
As these APIs are not truly universal on all editions of Windows, if an app were to program against them directly the app would not work on editions like HoloLens or Xbox.
Should Reunion warn the user about apps using this capability?
Some platforms periodically remind users that "App X is using feature Y, are you OK with that?"  How should Reunion make the user aware that a "low rights" application is using capabilities?

Duplicate issue #726: Allow setting the thumbnail of storage items through StorageItemThumbnail.WriteAsync
Created: 2021-04-14T01:14:27Z
Proposal: Allow setting the thumbnail of storage items through StorageItemThumbnail.WriteAsync

Summary

Currently, there is no way for UWP apps to provide thumbnails for storage items. There appears to already be an API for this, StorageItemThumbnail.WriteAsync, however StorageItemThumbnail.CanWrite always seems to be false, and attempting to write to the stream will result in an access denied error. This proposal is to enable setting the thumbnails for items through StorageItemThumbnail.WriteAsync.
Rationale


Thumbnails are often used as a preview of a file which makes it easier for end users to identify the contents of files, but unfortunately there currently isn't a way for apps to set item thumbnails (without using full trust) using universal APIs. UWP apps can only achieve this through the full trust process.
Developers targeting Windows 10x and HoloLens would be able to use thumbnails to enhance the user's experience when interacting with files. For example a PDF editor could set a thumbnail that consists of a preview of the first page of the document to make it easier for the user to identify the contents of the file.
Many apps (MS Journal, fluent screen recorder,  3D builder, to name a few) make a folder in a library to store documents, photos, videos, and other data related to the app. This proposal would allow developers to set a custom icon for that folder, making it easier for users to identify it.
Seemingly there is already an API that should be able to do this, it just doesn't seem to be implemented


Scope




Capability
Priority




This proposal will allow developers to set a StorageItem's thumbnail using StorageItemThumbnail.WriteAsync
Must


This proposal will allow applications to declare a thumbnail provider capability, similar to the one in win32
Won't


This proposal will allow applications to change the thumbnails of applications they don't have access to
Won't



Important Notes

Open Questions


How would this interact with user set icons on Windows 10?
Should end users be given a way to disable icon access, or reset the icons?
Should a new API be used instead of StorageItemThumbnail.WriteAsync?

Closing comment (2025-03-10T23:48:17Z): Related to #8.