Bugzilla – Full Text Bug Listing
| Summary: | Mnemonic collision between button and menu | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [RT] RAP | Reporter: | Stefan Milchram <stefan.milchram> | ||||||
| Component: | RWT | Assignee: | Project Inbox <rap-inbox> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | tbuschto | ||||||
| Version: | 2.1 | ||||||||
| Target Milestone: | 2.2 M1 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | sr211 | ||||||||
| Attachments: |
|
||||||||
I think the SWT hehavior described here is windows specific. In windows, mnemonics stay active even after ALT is released, while they are not in GTK or RWT. So in windows the mnemonics in the menu can overwrite the shells mnemonics while ALT is pressed. Not sure what happens in GTK (can anyone try this?). So unless we would change this fundamental difference between SWT-win and GTK/RWT, the windows behavior can not be exactly replicated. It should be possible to prevent more than one widget to handle a mnemonic and then give menuitems a higher priority. However, it would then no longer be possible to trigger the mnemonic on the button. Would that be acceptable? In GTK, the mnemonic on the Button is overridden by the mnemonic on the MenuBar. So giving the MenuBar a higher priority would match the behavior on GTK. As the behaviour is different troughout the SWT-implementations a solution in RAP should be customizeable. -) In general only one element (menuitem, button etc.) should be triggered when using a mnemonic, even more elements share the same -) A possibility to configure the priority of elements in case of collision should be added. So the RAP-developer could configure the behaviour to the one the usergroup is used to. This is especially interesting for single-sourcing applications as most of the users are used to the behaviour, and appliction mnemonics were set with this behaviour in mind. (In reply to comment #3) > As the behaviour is different troughout the SWT-implementations a solution in > RAP should be customizeable. I don't agree with this logic. SWT is a cross platform toolkit and SWT applications will show some minor differences in behavior due to platform differences. RAP is one of those platforms. We can discuss the best way to implement a certain functionality in RAP, but we can't make everything configurable. Configuration options always add complexity, make the framework harder to test and more prone to failure. We should keep things simple. As I see it, mnemonic collisions as the one described here should simply be avoided in SWT. > -) In general only one element (menuitem, button etc.) should be triggered when > using a mnemonic, even more elements share the same I completely agree with that. (In reply to comment #4) > I don't agree with this logic. SWT is a cross platform toolkit and SWT > applications will show some minor differences in behavior due to platform > differences. RAP is one of those platforms. We can discuss the best way to > implement a certain functionality in RAP, but we can't make everything > configurable. > Configuration options always add complexity, make the framework harder to > test and more prone to failure. We should keep things simple. Good point. As the Windows and GTK implementations differ also, which behaviour should RAP implement? (In reply to comment #5) > As the Windows and GTK implementations differ also, which behaviour should > RAP implement? GTK, since the windows implementation could be very tricky to imitate. Okay, we decided to go for a mix between GTK and Windows. Unlike windows, mnemonics will NOT stay active after the activator key has been released (as it is now). Like in windows, in case of a collision between menubar and other controls, the control get's the priority. This will allow to implement keyboard navigation for menu bars, for which a new enhancement bug has been opened (bug 414481). In a collision between widgets with the same priority only one of them will be selected, but which one is undetermined. In master this has been fixed with commit a5e9767d776263dc64af0e756a8ab12264739a7a. For RAP 2.1 SR1 I will attach a patch soon, which will only prevent the selection of multiple widgets, but not give menuitems the lower priority. Created attachment 234114 [details]
patch for 2.1
This prevents MnemonicHandler from triggering multiple widgets simultaneously
(In reply to comment #8) > Created attachment 234114 [details] > patch for 2.1 +1 to backport it to 2.1. The patch looks ok. Applied patch to streams/2.1-maintenance branch. |
Created attachment 233558 [details] Contains RAP and SWT snippets to compare behaviour When a button and a menu have the same mnemonic (for example "&File") in SWT the following happens: -) if you press ALT + F the button is pressed. -) if you press ALT, release and then press F the menu is selected In RWT things are different. As you are in the browser you define the modifier for mnemonics yourself, in our case its CTRL + ALT. The following happens: -) if you press CTRL + ALT + F the button is pressed and the menu is selected -) if you press CTRL + ALT, release and then press F the menu is not selected, as the menu is not selected when pressing the modifier as in SWT. See the attached snippets for easy reproduction.