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.
Summary: | shortcuts should not appear on submenus | ||
---|---|---|---|
Product: | platform | Reporter: | Rochelle Raccah <raccah> |
Component: | Window System | Assignee: | Petr Nejedly <pnejedly> |
Status: | CLOSED FIXED | ||
Severity: | blocker | CC: | jglick, jtulach, mvenkatraman |
Priority: | P3 | Keywords: | UI |
Version: | 3.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 26619 | ||
Attachments: | Probably working solution |
Description
Rochelle Raccah
2002-03-05 16:07:40 UTC
> 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. |