Bugzilla – Full Text Bug Listing
| Summary: | Shift F10 - using context menu key makes menu pop up in wrong place | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Mike Wilson <mikewse> |
| Component: | SWT | Assignee: | Silenio Quarti <Silenio_Quarti> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | carolynmacleod4, cocoakevin, markus.kell.r, michael.glass+eclipse, Mike_Wilson, nevicosi, pombredanne, Silenio_Quarti, sjanuary |
| Version: | 3.1 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | stalebug | ||
| Bug Depends on: | |||
| Bug Blocks: | 357532 | ||
|
Description
Mike Wilson
See bug 5892, bug 100557. *** Bug 100557 has been marked as a duplicate of this bug. *** *** Bug 71883 has been marked as a duplicate of this bug. *** *** Bug 180092 has been marked as a duplicate of this bug. *** How hard is it to fix this? Isn't it just a matter of recognizing that the menu request came from the keyboard rather than the mouse and using the view bounds rather than the mouse position when popping it up? The current behavior is actually irritating if you are driving Eclipse entirely via the keyboard. We don't know the bounds of the selection so it's difficult for us to place the menu in the correct location. In the future we could add API to let MenuDetect listeners know that the event is coming from the keyboard so that the location of the menu could be set at the application level. Not for 3.4 though. (In reply to comment #6) > We don't know the bounds of the selection... > I'm not sure I understand this. All I was asking for was to get the menu to pop up centered over the *control* that it is associated with. > All I was asking for was to get the menu to pop > up centered over the *control* that it is associated with. -1 for centering over the control. This would often make the menu overlap the selected item. I wouldn't start playing with this so late in the game... Note that e.g. the Refactoring and Show In quick menus (Alt+Shift+R/W) already implement this request (Plat/UI API request is bug 151711), but only for a limited set of controls (StyledText, Tree, Table). (In reply to comment #7) > (In reply to comment #6) > > We don't know the bounds of the selection... > > > I'm not sure I understand this. All I was asking for was to get > the menu to pop up centered over the *control* that it is > associated with. [Nice name, Mike :-)] I think what Kevin refers to is the functionality you can see in f ex Outlook, that when pressing the context meny key the menu will pop up just below the selected item in the focused control. Your suggestion is certainly an ok compromise on the way to that goal. (In reply to comment #6) > We don't know the bounds of the selection so it's difficult for > us to place the menu in the correct location. In the future we > could add API to let MenuDetect listeners know that the event is > coming from the keyboard so that the location of the menu could > be set at the application level. Not for 3.4 though. IMO this API should involve the application as little as possible and the SWT widget as much as possible, as the respective widget (f ex List, Tree or DateTime) has the best chance of saying where the menu should be placed depending on selection. Without being an SWT expert, I am thinking about something like having the widget fill these coordinates into the MenuDetectEvent, either in the existing x/y members or in new ones. The doc for WM_CONTEXTMENU Notification states that the menu should be placed at the location of the current selection when the context menu is opened from the keyboard. In my previous comment I was essentially saying that we don't always know where the selection is so we can't always locate the menu in the correct place. API would be needed in this case to tell users in the Show event that the menu was opened from the keyboard. Centering the menu over the control is a potential workaround, but as Markus stated, this could obscure the current selection. I don't know if that would be more or less disruptive to users than our current situation. To be honest, I just don't open context menus from the keyboard enough to have an opinion either way. I'll try making a patch that centers the menu over the control. (In reply to comment #9) > [Nice name, Mike :-)] > Indeed! That's one of the reasons why I ended up being called "McQ" -- there seem to be lots of those in the world too, but many fewer than the number of Mike Wilsons. Because a menu can be opened in a number of different ways, this is more complicated than just detecting a key press and using a different location. We tried to find a solution, but feel it's too late to make this change for 3.4. Ok, bad luck, but I'm still very happy that you have started working on it. (hey, getting it fixed in 3.5 will just be an 0.4 increment since I reported it ;-) When you do plan your design changes I would you suggest you look at https://bugs.eclipse.org/bugs/show_bug.cgi?id=75766 at the same time, as there may be some overlapping concerns on how to distribute widget vs framework responsibilities. Best regards Mike So can we put the 3.5 target on this? Sure. > I am thinking about something like
> having the widget fill these coordinates into the MenuDetectEvent,
> either in the existing x/y members or in new ones.
My thoughts as well. We'll need to implement something for each native control. To implement this for custom controls, they can listen for MenuDetect and set the x and y fields in the event for subsequent listeners in the chain.
Hi Steve, Is there an outlook for this defect? Is it going to be fixed in Eclipse 3.5 (as it's currently targeted at)? This is currently affecting our accessibility test. Thanks, Kathy Actually, this problem was found during our accessibility test but does not really affect accessibility. So you could ignore comment #17. As a first step in fixing this bug, new API was added so that custom controls can tell if the menu detect is from the mouse or keyboard. This lets them set the x, y location of the context menu based on control-specific selection or focus. This will be in 3.8/4.2 M6 (API freeze milestone). See bug 374147 for details. (In reply to comment #19) I've released bug 374320, so that the new API will be used in the Open Context Menu command. Filed bug 375723 and bug 375721 for follow-up problems. (In reply to comment #20) Thanks, Markus. I am just getting to these today. I really appreciate that you have given inspirational sample code in those 2 bugs. :) I'll be in touch. In 3.8/4.2 M7, Windows 7, custom context menus are now placed at the control's desired location when I press the menu key or Shift+F10. The native Text menu always opens centered on the Text control and doesn't use the same location as a custom menu (which opens below the caret). This may just be OS behavior. But non-native menus are not all handled the same: - On Table, Tree and Text, Shift+F10 uses SWT's location, but the ContextMenuHandler doesn't get SWT's location when it sends the SWT.MenuDetect event as suggested in bug 374320. - In contrast, StyledText handles the SWT.MenuDetect event and thus places both the Shift+F10 menu as well as the ContextMenuHandler's menu at SWT's location. The behavior of native control and custom controls should be the same, preferably that both us SWT's location all the time. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the stalebug whiteboard tag. Hi folks, thanks for keeping this work going! Not long after I reported this bug in 2005 :-) I switched to Linux and haven't had a daily Windows dose since. Anyway, I dug up some old (and installed some new) Eclipse versions on my Windows box and tested the scenario I reported in the original bug text. This is the result: Eclipse 2019-12/Win10/64-bit: fixed Eclipse 4.6.3/Win10/64-bit: fixed Eclipse 4.6.3/Win7/32-bit: fixed Eclipse 4.2M3/Win7/32-bit: not fixed Eclipse 3.7/Win7/32-bit: not fixed So seems all good from what I came across in 2005. I haven't checked if there are other special cases that would fail according to Markus's comment from 2012. Thanks all! |