In some cases they do.
For example a GTK app main context menu can be triggered with F10. But this relies on the developer to correctly "tag" said context menu.
In simple cases it is obvious what to do, but in more complicated designs, where you may be able to achieve the same visual output in different ways, it may not be so obvious.
In that case, it is up to the developer as well to read and try to follow the published guidelines.
So in none of the cases they do - it shouldn't depend on any tags, that's the whole point of bypassing the app devs!
(not that the tags shouldn't exist, they can make customization easier, just that they shouldn't be necessary for any framework menu components)
What complicated designs do you have in mind?
Maybe not complicated, but unorthodox. A developer who is not familiar with the correct design patterns may, for example, create a dialog using a FrameworkWindow instead of a FrameworkDialog. In that case the framework can not provide any automation, because the developer is not following the guidelines.
I would argue that any sufficiently powerful framework also provides more ways to diverge from the "proper way", so it puts more pressure on the developer to actually study and understand the framework design patterns.
But a framework can provide user keybinds conditional on that Dialog-As-Win being shown so users could reclaim some of that lost automation
And more pressure from more options doesn't follow, you only need to study if you actually want to diverge
> But a framework can provide user keybinds conditional on that Dialog-As-Win being shown so users could reclaim some of that lost automation.
The "conditional" is carrying a lot of weight here. The developer needs to know what to do. For example, in my GTK application I had to learn how to identify a menu as the "primary" menu, so that the framework will automatically bind it to the well-known shortcut.
This is easy to omit and then you will never know about the automation.Then, you can go into a different discussion. How does the framework guide you to the correct functionality? Does it force you to include a primary menu? Does it check that if you have at least one menu, then one should be primary? What if the developer creates an unorthodox menu by creating a simple button that opens a popup with a list of buttons?
> The developer needs to know what to do.
No he doesn't, your primary example is the same thing - your menu is uniquely identifiable, so a user can configure F10 to open it if you, app developer, forgot to mark it as main (by the way, how did it compile if you have no main prop? Then it's not easy to forget, "framework guide you to the correct functionality?" indeed)
> What if the developer creates an unorthodox menu
What is he draws a circle instead of using a letter O? What of it?