Community
Participate
Working Groups
Some views (e.g. the Package Explorer) have a pulldown menu on the right (a black triangle). Clicking the left mouse button on the triangle and holding it down should show the menu (that's a Windows standard behavior). The menu only shows up on mouse up, which is too late.
The behaviour you are suggesting is different than the windows behaviour. In Windows you can have a left click and a right click menu (look at the pulldowns on the tool bar in IE). We would be inconsistent if we made these the same menu. We don't have a menu bound to the toolbar so not having a menu popup when you right click is the correct behaviour.
Marking as WORKSFORME
Seems my description wasn't clear enough. I'll try again: I'm *not* referring to context menus (right-click menus). I'm talking about the menu in a view's title bar: - if the view is not a fast view, it's the second item from the right (next to the close button) - icon is a big black triangle - tooltip says "Menu" - opens on left mouse click What's not cool about it is that I have to *release* the mouse button to make the menu appear. Usually, I can press the left mouse button down on a menu, drag to a menu item, and release the mouse button to activate the item.
Ah - I see the issue now. I thought you were advocating having the same menu for left and right mouse click. The behaviour you are talking about is supplied by SWT.
ViewPane.SystemContribution.fill(...) adds a SelectionListener to the ToolItem for notification of when to display the menu. A ToolItem Selection event will only ever fire after mouseDown+mouseUp, same as for Buttons. So to make the menu appear sooner, MouseDown needs to be hooked instead of Selection. Moving to UI.
Grant, isn't the gesture for activating menus platform-specific? The MenuDetect event is supposed to abstract away the details, but I believe it really only represents the context menu gesture, and wouldn't be applicable here (and you can't currently hook this event on a ToolItem anyway). Is the gesture for activating pull-down menus platform-specific, or just the gesture for context menus?
I've checked all of the platforms except Photon, and they're quite uniform w.r.t. pull-down menus. The variations I saw occurred when I did a MouseDown on the pull-down item, dragged somewhere other than the newly-displayed menu, and then did MouseUp. In this case win32 kept the menu up, while the others dismissed it. MenuDetect would be strange here since the ToolItem is just a PUSH which shows a menu when it's pressed. MenuDetect might make sense for DROP_DOWN ToolItems, but that's a different case than here.
*** Bug 61307 has been marked as a duplicate of this bug. ***
I took a stab at fixing this over the weekend. It's a lot harder than it looks. If you try to open the menu on mousedown (as per comment 5), the ToolItem gets permanently stuck in its "down" state, even after you close the menu. That is, it will still look like you're clicking on the dropdown even after you move the mouse away. (Presumably the mouseup gets lost after we open the menu) This can be fixed by changing the ToolItem to a separator or disabling it. In this case, the toolitem doesn't change its appearance when you click on it.. but then we lose the mouseover affordances, which is almost as bad as the original problem. It also might be possible to fix this by tricking the ToolItem to go back to its normal state immediately before opening the menu (this is what toolitems created with SWT.DROP_DOWN seem to do). I tried toggling its visibility, enablement, forcing a redraw, moving focus, etc... and I could not find a way to cause the ToolItem to draw itself in its default state before the user lifts their finger off the mouse. It would work if we used a completely rendered widget, but that seems like overkill (and it would take some effort to make a custom widget that provides exactly the same mouseover affordances as ToolItem does on all platforms). It looks as though more SWT support is needed to fix this. At minimum, ToolBar should be able to support a mousedown listener that opens a popup menu over an SWT.PUSH ToolItem (comment 5).
Moving to SWT for comment. Can we get something akin to SWT.MenuDetect but for drop-down menus rather than context menus?
SWT.MenuDetect doesn't really make sense here because menus are normally requested on mouse up for button 3 on Windows, not mouse down. SWT.Selection can't be used because this normally happens on mouse up for button 1 when the mouse up occurs within the tool item. What you are trying to do is use a tool item like a menu bar item by dropping down the menu on mouse down. This is an odd use of tool items. Normally, when a drop down menu is needed, an SWT.DROP_DOWN tool item is used. This displays a menu on mouse down, but doesn't draw the way you want (it draws an icon and a small triangle). So, I have fixed the cheese problem on Windows but since this is an odd thing to do to a tool item and most applications use SWT.DROP_DOWN when they want to add a menu to a tool item, I'm not crazy about adding new API. Using mouse down and hit testing the tool item will work. Fixed > 20041109 (cheese only)
Steve: your fix only seems to fix a sidenote in comment 9. The original problem is not fixed and the bug should be moved back as requested in comment 10.
I am leaning towards not adding the API.
Steve: It would be great if there were some "accepted" way to use toolitem as though they were a menu. I agree with Nick that SWT.PUSH + mousedown listener is a bit of a hack. If there were some way to change the appearance of SWT.DROP_DOWN to what we wanted, this would be pretty near perfect.
The patch to bug 62280 includes a fix to this PR.
Steve, one reason for requesting new API for this is that I thought the gestures for invoking a pull-down menu differs on different platforms, so the UI shouldn't hardcode it as mouse down.
Stefan: I agree. I looked at getting SWT.DROP_DOWN items to hide their triangle and couldn't get it to work. Nick: But the UI is hard coding the mouse gesture. On Windows, SWT.MenuDetect is normally button 3 up. You want the tool item pop up a menu on button 1 down on every platform. So the title of this bug report isn't quite right.
I suspect Nick isn't too particular about whether the listener gets a SWT.MenuDetect event or something else. The important bit is that whatever mouse gesture works for the main menubar should also open the view dropdown.
If there are no platform dependencies for the drop-down menu gesture (it's mouse down everywhere), then it sounds like Steve's cheese fix and Stefan's existing patch will work, and no new API is needed. Moving to Stefan to confirm/close when patch is released.
Looks like the patch to bug 62280 isn't going in. I've extracted the bits that relate to this PR and prepared a fix for M4. Fixed in HEAD. cc'ing Doug since this should end up in our build submission.
The mousedown trick is causing problems on GTK. I'm reverting this patch until we have time to investigate properly. Billy, can you describe the behavior you're observing?
See Bug 80948
This has been rolled back in HEAD. Steve, there seems to be some event ordering differences between Windows and GTK. Even on windows, this didn't behave perfectly: 1. clicking twice on a windows menu closes the menu, but the mousedown+toolbar trick leaves it open. 2. On a windows menu, if you click and drag on a menu but let your mouseup fall somewhere off the menu, it will close. With the mousedown trick, the menu stays open. Bouncing back to SWT: It looks like what we really need is a widget that behaves exactly like a menu, but can contain an image.
*** Bug 80948 has been marked as a duplicate of this bug. ***
Correction to comment 14: a ToolItem with SWT.DROP_DOWN wouldn't have the correct behavior either, since it doesn't close the menu if you drag off the dropdown.
A fix for the GTK+ "menu disappears" behaviour has been released in HEAD.
Okay, I've put back the mousedown patch. This releives the symptoms somewhat on most platforms, but it is still not perfect. I'll leave this open until the view menu behaves exactly like a menu on all platforms.
With this change, the view menu now acts like a normal menu on GTK+, except for the problem described in bug 81891.
Can we close this bug report?
No... it is greatly improved, but still not exactly like a native menu (at least on Win XP). On Windows, if you use mousedown to open a menu and drag your mouse off the menu such that the mouseup arrives elsewhere, the menu will close. Currently, the view menu will remain open.
I'm not sure if this last issue should be addressed by SWT or the UI. UI could probably solve this by attaching a global event filter which listens for a mouseup event on a different widget from the view menu chevron, and close the menu if this occurs. SWT could solve this by offering a new widget (or toolitem style, etc.) that creates something with a dropdown menu that behaves exactly like a menu on the native platform. SWT could also solve this by changing the behavior of popup menus on Win XP: if a popup menu is open and a mouseup arrives on any widget other than the popup menu or the widget that received the mousedown, then close the popup menu. This would be more consistent with the windows top-level menus. Thoughts?
Without knowing how hard it would be, the second idea sounds best to me because it would "behave exactly like a menu on the native platform". The other ideas sound like they're trying to just emulate what the platform does but there's no guarantee it will feel native on each platform.
I'm sorry but we didn't get to this for 3.1.
I've seen native applications work the way that Eclipse works for these little down-triangle menus. For example, in the toolbox menus in Word 2002, it works the same way. So I'm happy with the way it is currently working under Windows in 3.1M6.
The current solution is also fine for me, since it is a major improvement for the normal workflow. OK to resolve the last non-nativity later (or never ;-).
I'd like to see this fully fixed, especially since we're so close. I'll be happy to write a workaround in the UI code, but I first want to wait for SWT to decide if they're going to support this directly.
I think we'd need new API to really support this properly, something like ToolItem.setMenu(). Since we are API frozen for M6 and we are working on other things, it won't happen for 3.1. Personally, I'd just leave the menu coming up on mouse up. It seems like a lot of work for not much benefit.
It's much more useful now than the way it used to be (it used to wait until mouse-up). I vote for declaring victory and closing the bug.
To be honest, that's the way I always close menus so I personally notice it all the time. :-)
Just found some other platform inconsistencies: On windows, if you give a menu keyboard focus and press down, the menu opens. If you give a toolbar button keyboard focus and press space, the button activates. The current keyboard behavior doesn't behave like either a menu or a toolbar dropdown.
*** Bug 79049 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 139318 ***
Oops, wrong dup.
*** This bug has been marked as a duplicate of bug 193318 ***
