| Summary: | Context menus appear far from where the user clicked | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Billy Biggs <billy.biggs> |
| Component: | SWT | Assignee: | Bogdan Gheorghe <gheorghe> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | billy.biggs, cocoakevin, eclipse.felipe, ericwill, ipun, overholt, snorthov |
| Version: | 3.1 | Keywords: | triaged |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux-GTK | ||
| Whiteboard: | |||
CC'ing Steve to get his opinion. You have the right idea but I'm not sure we can use/should use the public API. The problem is that we don't run the menu right away in setVisible(). We need to check with Felipe as to why we need to do this. For example, on Windows, setVisible() ran a modal loop leading to non-portable code. We had to defer it to the event loop. GTK doesn't run the loop so I wonder why we are doing it. It would be nice to get this change in for 3.1 as I noticed it again. Felipe, do you know why we don't just show the menu like Steve suggested? Billy, it doesn't look right. Pls, come see me for details. Steve, it is a long history. It all started back in Boris' days...Basically, we couldn't fire show menu in button press cause at that point the selection (in a tree) was not updated yet. So we changed to do the work in event after, then bug 37428 came along. We needed code in keydown to stop the system menu (in entry, etc) when a user menu is install, so we had to run show menu in button press to be able to stop the system menu, but we could not bring the menu up at point. The solution was the import the display addpopup, runpop framework from win32 to gtk... and all worked fine ever after. (I'm pretty sure I forgot some small details of this history like crashes, GPS, and hangs. Really, there is no happy ends.) Ian, this might be relevant to your menu bug. there has been some updates to how menus are drawn (as of deprecating gtk_menu_popup() from Bug 505992 ). I will follow up on this if this is relevant still in a week. *** This bug has been marked as a duplicate of bug 431423 *** |
The context menus in Eclipse do a lot of work in their SWT.Show handler. By the time the menu goes to pop up, the mouse cursor may have moved far from where the user clicked. It would be better to use the cursor position of the original click. I can reproduce this problem on both Windows and Linux-GTK+. The following is a trivial patch to fix the problem but I am not sure yet if it has any side effects (can you do setVisible(false);setVisible(true); multiple times on menus?). Index: Eclipse SWT/gtk/org/eclipse/swt/widgets/Menu.java =================================================================== RCS file: /home/eclipse/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/Menu.java,v retrieving revision 1.62 diff -u -r1.62 Menu.java --- Eclipse SWT/gtk/org/eclipse/swt/widgets/Menu.java 16 Dec 2004 21:47:44 -0000 1.62 +++ Eclipse SWT/gtk/org/eclipse/swt/widgets/Menu.java 7 Jan 2005 21:29:39 -0000 @@ -866,6 +866,9 @@ checkWidget(); if ((style & (SWT.BAR | SWT.DROP_DOWN)) != 0) return; if (visible) { + if (!hasLocation) { + setLocation (display.getCursorLocation()); + } display.addPopup (this); } else { display.removePopup (this);