Community
Participate
Working Groups
Build: M8 If you right click on a view or editor tab the part realizes and then the pop up menu appears. Sometimes I want to close the part without it realizing (especially when the part is expensive to realize, like the hierarchy).
If you use the close button (for editors only), that should not activate. Right clicking on the tab selects the tab first, which you want, so I don't see how we could do this. Did you have some other interaction in mind?
In some applications, right-clicking on a tab does not select the tab. This is what I would normally consider "expected behaviour".
Reassigning bugs in component areas that are changing ownership.
I wholeheartedly agree with this suggestion. In fact, I'm not sure it should be considered an enhancement. The behavior, as is, is inconsistent with the Windows GUI. Changing focus and selecting are two different things. (There's likely an MS doc somewhere specifying this.) I'll spare you more examples from other apps, but take tabs in Firefox (2.0 at least) as example. They have mouse-over focus, and if you right-click, you get the context menu for that GUI element. Right-clicking is more of a command to the element's parent than to the element itself. Although my Java UI knowledge is rusty, I know that that isn't really OO, but shouldn't emulating this behavior come under native OS integration?
The enhancement request sounds reasonable. Unfortunately, we don't have the resources to work on this at this point.
Upon investigation, this will not be possible unless SWT first chooses to "ignore" secondary mouse clicks on unselected tab items. Please see bug 258727.
This bug is distracting and should easy to fix (so I imagine). Related problem: If I double click the back (or foward) (or middle) button over the tab area it will maxime the editor. It should only happen when clicking with the left button.
To fix this bug, we need to alter the code in TabbedStackPresentation like so... public void showSystemMenu(Point displayCoordinates, IPresentablePart context) { - if (context != getSite().getSelectedPart()) { - getSite().selectPart(context); - } systemMenu.show(getControl(), displayCoordinates, context); } ...unfortunately, while this resolves the problem described in the summary, some of our menu items no longer work properly. From a preliminary investigation, attempting to make the selected view a fast view or a detached view will instead cause the action to be performed on the currently active view instead of the view that has been selected.
Created attachment 124918 [details] Prevent part activation on context menu patch v1 This patch should rectify the problems outlined in comment 8. However, 'New Editor' does not work because it is a handler that checks for the workbench page's active editor. As a result, it will spawn another instance of the active editor instead of the editor that has been selected by the mouse.
I guess we are lucky because for once, that menu is not extensible and not API, so we'll be able to just fix our handlers. Right?
(In reply to comment #10) > I guess we are lucky because for once, that menu is not extensible and not API, > so we'll be able to just fix our handlers. Right? Well, I'm currently having a lot of difficulty retrieving the CTabFolder from the menu item's selection event. The handler needs to somehow be aware of where the user originally clicked and then we need to use some SWT means to retrieve the underlying CTabFolder from that and try to identify the selected editor from there.
Created attachment 124983 [details] Prevent part activation on context menu patch v2 This patch "leverages" Widget's setData(Object) so that we can get the correct editor in the NewEditorHandler class.
< capturing info from our call this morning > For the right-click case it's a bit problematic to not activate the part. What part does 'Close' refer to, the one clicked on or the active one? It's a context menu and part of the context is which part is active.
I'm even more leery of tunneling under the context using 'setData'...;-).
(In reply to comment #13) > For the right-click case it's a bit problematic to not activate the part. What > part does 'Close' refer to, the one clicked on or the active one? It's a > context menu and part of the context is which part is active. I'm not familiar with the code of eclipse and my Java is rusty, so if "context" refers to anything more specific than the generic one in UI programming, I'm not using it. That being said, a few observations: The time of day is part of the context, too, but it's not relevant. The cursor location is certainly part of a mouse-invoked action's context. If 'close' referred to the active tab, why would it matter where on the screen you right-clicked--shouldn't you maybe always get a menu with a 'close' option that closed the active tab? If you right click within the active tab, you don't see a 'close' option, right? Location can determine what's available in a context menu to begin with, so why couldn't it determine the meaning of what does appear in it? In summary: The behavior of a shortcut menu is up to an application. This enhancement would allow the user to do something they can't do now (close an inactive tab without having to wait through potentially considerable swapping). There's an entire left mouse button available to make an inactive tab active. Why indiscriminately build that into all the actions accessible through right-clicking as well?
I don't think anyone has an issue with the middle button being used as an explicit 'close' shortcut (we're working on making that not activate the part) but there has been some discussion as to whether not activating on the context menu was the right thing to do, I was just presenting what was discussed. To Activate or not to activate, that is the question...Boris ?
(In reply to comment #16) > To Activate or not to activate, that is the question...Boris ? my vote: do not activate. note, the 'close with middle button without activating' behaviour is present in IE7 and Firefox. In these two apps you can also get the context menu for a tab item without activating it. Also note that thse two apps have a distinguished hot look when the mouse is over a tab.
Remy is now responsible for watching the [ViewMgmt] category.
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.
