Is your feature request related to a problem? Please describe.
Although shell menu items can be used for integrating third-party apps, things like QuickLook can't be done that way and we need to modify Files UWP to support these apps which leaves closed-source apps in the dust. Also if that app is open-source, it can change so we need to maintain the integration.
Describe the solution you'd like
Similar to many Web Browsers and IDEs, we can add the ability to install extensions. These extensions can improve your experience and can also integrate with third-party apps.
Describe alternatives you've considered
None.
Additional context
Windows 10 provides great APIs to easily add an extension model. Microsoft's own apps like the legacy Microsoft Edge and Photos, use these APIs for extending their functionality. Check this out: https://docs.microsoft.com/en-us/windows/uwp/launch-resume/how-to-create-an-extension. The APIs are a bit generic and underpowered but we can make use of them.
Issue Label Bot is not confident enough to auto-label this issue. See dashboard for more details.
Integrations with other applications will be possible when #174 is implemented.
@yaichenbaum You don't get my point. Shell context menu can be used to open other applications. They can't do more. Eg: QuickLook. To integrate with such apps we have to currently modify the source of Files and we should maintain it. Instead, it's better to make these integrations as extensions so the user only installs what's required. Also, the developer of the app can maintain the integration without us having to deal with so we can focus on improving the core experience rather than these integrations. With this, closed-source apps should be able to integrate without leaking source code.
@yaichenbaum I think @Jaiganeshkumaran is referring to add-ons/app extensions (more details here and here)
Add-on support wouldn't have to be just for context menus and integrating other applications. If it's do-able, it could be used to add support for extended properties for file types that have more metadata than the current properties dialog, e.g. video details as in #1103
Add-ons are separate to the main application, so they can be developed independently to the main Files UWP and as @Jaiganeshkumaran mentioned, users would also be able to install just the add-ons that they need.
If add-on support was added, a few template's could be created, this would allow developers a quick and standard way to implement additional functionality without having to make changes to the Files UWP core application.
Here's an example of Microsoft Emulator, note the add-ons section

Add-ons and app extensions are not the same. Add-ons as shown on the screenshot are small packages that can contain optional assets and code. These are managed by the host application and appear on the Store. App extensions, on the other hand, are standalone UWP apps that can communicate as an optional package but they are just regular apps. The first link teches how to create an app extension but the second link says how to upload an optional package (add-on). Since app extensions are standalone apps, they aren't listed as add-ons on the Store and they don't need the host app to run unlike add-ons. We can consider using both technologies add-ons for optional packages and extensions for integration with other existing applications like Bulk File Rename.
We can actually use add-ons for making Files UWP compatible with Windows 10X without switching to WinUI Desktop. It's not clear whether Windows 10X will have the Win32 container at first or not. By using this, we can get all the features but also supporting non-Desktop devices.
We can actually use add-ons for making Files UWP compatible with Windows 10X without switching to WinUI Desktop. It's not clear whether Windows 10X will have the Win32 container at first or not. By using this, we can get all the features but also supporting non-Desktop devices.
We are in touch with Microsoft about Windows 10X support, nothing to share just yet but it may end up working without any major changes.
Even if Windows 10X supports it we could make the FullTrust component as an optional package so that users don't need to install the FullTrust package on devices like the Xbox so they can save disk space.
For app extensions (not add-ons), we can provide project templates that are extremely similar to the default template but configured for integration with Files UWP. I'm investigation on how to use App Extensions for third party integration.
FYI: #2124
Most helpful comment
@yaichenbaum You don't get my point. Shell context menu can be used to open other applications. They can't do more. Eg: QuickLook. To integrate with such apps we have to currently modify the source of Files and we should maintain it. Instead, it's better to make these integrations as extensions so the user only installs what's required. Also, the developer of the app can maintain the integration without us having to deal with so we can focus on improving the core experience rather than these integrations. With this, closed-source apps should be able to integrate without leaking source code.