Proposal: simple context menu entries in app manifest #1082
Comments
|
FYI @ChrisGuzak. Agree that the current approach is unnecessarily complicated. |
|
There are some bigger questions to ask in relation to this.
|
The change was made mostly to bring organization to the menu (for example when an app has more than 1 entry, it's automatically put in a submenu, and all app entries are in the same region of the menu). We are not working around it, there is a documented way to add your own entries in there, it's just needlessly complicated.
If there is more than 1 entry from a single app, Windows 11 automatically puts them in a submenu. And I don't see this as a valid point, seeing as there's already a way to add entries there. Allowing users to hide entries is also a could in the scope table.
To name a few:
These are the ones on my system, there are most likely many more out there.
See ShareX above.
This still adds deployment and build complexity. You need to ship a different binary for every architecture, even though your app would otherwise be architecture neutral. You also need the C++ build tools installed, and to have your build system capable of building C++ (e.g., packaged Electron apps can't as easily add C++ stuff to their build). It's a maintenance burden for people who do not know C++ well, as well. Template Studio is VS-only (and an optional extension install), so a template added there would not reach a significant part of the audience. |
What's the source for this explanation?
My point was about this being a request to make it easier to add entries to the context menu. If such a change was made and it was then promoted on the grounds of "we've made it easier to add windows explorer context menu entries." Many developers would see this as an excuse to add such an entry for their app too, regardless of whether it makes sense or adds value to the people using the app. (I make this claim based on years of watching developers add pointless and irrelevant features to their apps because they're new and/or easy to do. "What's the harm they feel?" And then users end up with a context menu full of irrelevant entries and the Windows team has to come up with another way to reorganize and prioritize all the entries. My request for metrics was meant for the Windows team.
Is being VS-only a big blocker for this given that it's a Windows-only feature? My reason for suggesting this as something that could be added to Template Studio is that this feels like a very niche request and so is unlikely to be something that would quickly get up the priority queue for a change in the build system. Adding templates would be a couple of days' effort at most and would then at least make the process simpler. It's also something that could be community-contributed rather than waiting for a space in the WindowsAppsSDK backlog. I suspect (and hope) there are a lot of other things that are a higher priority and would be done first. Still, this is all good extra context for those who make the decisions. |
Right here and here. All of the points listed are organizational changes. The OP is about being able to show up in the new Windows 11 menu, not the old one under "show more options", without needing to implement
That's why "This proposal will allow end users to show/hide undesired context menu entries from the Settings app" is a could. Collapsing apps with multiple verbs under a dropdown also helps it from being invasive. The menu is also more organized by default because app verbs are all grouped under the same subsection of the menu
Then it's not possible for me to answer that in an appropriate manner, since I am not a MS employee with access to Windows telemetry that could provide this data. I can only speak of personal experience.
Yes, as there are many Windows apps which are being developed without Visual Studio. For example Electron, React Native, Rust, MSYS2/mingw, etc. In all of those except one, integrating C++ code is a pain. |
|
Please provide an option to completely disable all third-party context menu items and just have the default ones. |
|
Allowing users to hide entries is also a could in the scope table. |
|
Thank you for the thorough suggestion! One thing I want to quickly clarify is that IExplorerCommand will run Out of Proc when invoked in the way described in the blog post and sample. |
|
Thanks for the info! I tried to find information of whether This does remove concerns with regards to managed implementations (which is awesome), but I think there is still value to simplifying it, as this is currently additional complexity to adopting packaged support for some apps (where the unpackaged version just directly registers context menu verbs in the registry instead of using a shell extension). Or just additional complexity in general compared to writing a few entries in XML. |
|
Out-of-proc support extends back into Windows 10 for some time but the documentation needs work. I agree we should consider making this easier. We're discussing options internally. |
|
We're chatting in another thread already but just want to mirror here. There doesn't appear to be a good story for folks that were previously just doing: (This just calls Right now, it appears I have to write an app, take a dependency on a runtime/process creation API, package it (or sparse package it), sign it, deploy it, all to simply shell out to an executable. |
|
This is why we have "Show more options" - it's important to recognize that it's still possible to add a Shell extension in this way, but it's no longer easy to put it at the top level of the context menu. |
|
I'm going to imagine at some point in the future there'll be an app that registers its own shell extension under |
|
yeah I was planning on doing something like that next week :) LMK if you want to collab :) |
Let's hope we can get rid of this once microsoft/WindowsAppSDK#1082 gets implemented.
|
Any news? |
|
Any progress? |
Proposal: simple context menu entries in app manifest
Summary
Support declaring a context menu entry with a specific icon, display name and executable in app manifest instead of requiring to provide an
IExplorerCommandimplementation.Rationale
IExplorerCommandIt also requires implementing it in C++, as C# and other managed languages are heavily discouraged by Microsoft for in-process shell extensions (andIExplorerCommandindeed only supports in-process activation).This will cause the DLL to be loaded in any process with a save as/browse dialog, causing potential runtime version conflicts. So, even if one disregards the MS recommendations and goes ahead with a managed implementation, this will cause problems in the real world.Scope
Important Notes
The app manifest entry could look something like this:
In command line arguments,
%1is a placeholder for the file/folder name, if any.One could then use activation APIs to determine if the app was launched in response to a context menu entry (or for Win32 apps, they can read command line arguments). It wouldn't be unlike the File activation API:
namespace Windows.ApplicationModel.Activation { public enum ActivationKind { + ContextMenu = 1023 } + public sealed class ContextMenuTargetActivatedEventArgs : IActivatedEventArgsWithUser + { + public string ItemType { get; } + public string Verb { get; } + public IStorageItem? File { get; } // null if something like Directory\Background was activated + } } namespace Windows.UI.Xaml { public class Application { + protected virtual void OnContextMenuTargetActivated(ContextMenuTargetActivatedEventArgs args); } }Command line arguments are supported to simplify the migration of an existing Win32 app to MSIX, as the app might already have command line arguments for context menu entries and adding code checking for the activation kind is not possible or too costly. It's not needed for UWP/Windows App SDK apps, which use activation from the start.
Open Questions
None that I can think of.
The text was updated successfully, but these errors were encountered: