This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
In certain cases, Paste ends up with a submenu instead of a single action. In that case, the shortcut ctrl-v still appears on Paste (the menu). According to Jesse, this results in the first action in the submenu being performed, but it was agreed on nbui that this is incorrect behavior and the shortcut should show up on the menu item in the submenu. Paste is just an example, but the code should be checked for other examples of this.
> Paste is just an example, but the code should be checked for other > examples of this The opposite is true. Paste action is very special.
assigning to pnejedly, our menu expert
OK, I'll look at it
Created attachment 5683 [details] Probably working solution
I have solution that works for Paste, but it is completly unrelated to PasteAction, it fixes the behaviour generally for any SubMenuBridge that oscilates between 1/more items. As I maybe a Menu expert but certainly not Actions/Bridge expert, I'd like someone to review my changes. Yarda/Jesse?
I see no reason why this should not work.
The patch doesn't make any sense to me. How do you know the shortcut will in fact invoke the equivalent of the first submenu item?! This is true for PasteAction, but there is no guarantee it will be true for other cases, other than a feeling that it sounds like good UI for it to be true.
Hmm, then how'd you like to fix it? The Ctrl-V will invoke PasteAction without any way of specifying which kind of Paste it will perform. The SubMenuBridge shoud never display a shortcut for a submenu invoking item, this is easy and is already part of the patch. I don't know how to easily propagate the shortcut to the PROPER (it don't have to be the first, according to Jesse) item in the submenu except enhancing the Actions.SubMenuModel inteface.
Since Actions.SubMenuModel is an interface and cannot be compatibly extended, perhaps we can just use the above patch even though it is known to not be necessarily accurate. It should at least be an improvement, and if some action appears later for which the default submenu choice is not in fact the first one, we can reopen this and consider how to fix the SubMenuModel interface - or simply deprecate SubMenuModel and SubMenuBridge and ask people to write their own menu presenters to begin with, which may well be simpler.
OK, I'll commit it tomorrow. In fact, I don't like the implementation of Bridges as they try to be too smart instead of being short-living Presenters. Is this "problem" covered by the Commands API already or should I start pushing it in The Right Direction(tm)?
Integrated.
verified in [nb_dev](20020530)
Resolved for 3.4.x or earlier, no new info since then -> closing.