Community
Participate
Working Groups
Found while investigating Bug 348398. Double clicking to maximize/unmaximize works inconsistently based on the fix on bug 348398. However, using the buttons/actions to max/min the view always loses focus.
I don't know if I will find a solution for this in M6, but it should be of similar priority to bug 348398, so I'm marking it for 4.2 M6.
Curtis, can you provide a bit more info on what you were doing ? I have a suspicion that you maximized a part with an empty editor area but I'm not sure. I'm unable to reproduce this just playing with M6, double-click, buttons and Ctrl-M all seem to maintain focus on the active part..
Sorry about the slow reply, still a few cases are not working for me. Tested using the Problems View, with several editors open and several views stacked with the problems view. 1) Have a selection in the problems view. Double click the tab to maximize. Now the tab has focus, not the view part. (The view part does retain focus if the maximize button is used) (The view part also retains focus if the double click happens outside of the tab). 2) Have a selection in the problems view. Click the minimize button. Click the problems view icon to pop it open. Check that there is still selection and focus on the popped open view. Click the restore button. View no longer has focus (not sure if any part has focus). Interestingly, minimizing the view, popping it open, then double clicking to maximize (combo of 1 and 2) keeps focus correctly.
I found that minimizing the view keeps focus correctly. Maximizing looses focus. The problem seems to be in StackRenderer$8.mouseUp(): // If the user clicks on the tab or empty stack space, call // setFocus() if (e.button == 1) { if (item == null) { Rectangle clientArea = ctf.getClientArea(); if (!clientArea.contains(e.x, e.y)) { // User clicked in empty space item = ctf.getSelection(); } } if (item != null) { MUIElement ele = (MUIElement) item.getData(OWNING_ME); if (ele.getParent().getSelectedElement() == ele) { Control ctrl = (Control) ele.getWidget(); if (ctrl != null) { ctrl.setFocus(); } } } } As far as I can tell, the above code only deals with the "empty space" part, not with the "clicking the tab" part. When maximizing, the mouse event coordinates are not outside of the (new) client area, hence the item is not retrieved, and setFocus() is not called.
Piotr, thanks for the info ! I think you may have figured this one out, want to try for a patch..;-) ?
hello Eric, I will try, but this is not a trivial problem. The real issue is, with a double click there are two mouseUp events. The second one appears after the view has already been maximized. The mouse coordinates are checked against where the view is now, rather than where it was at the point the click was made. This doesn't make any sense, and it causes CTabItem item = ctf.getItem(new Point(e.x, e.y)); to fail. This is where the code is supposed to handle the "user clicked the tab" case, but the tab is in a different place already. Any hints are welcome.
Created attachment 225291 [details] patch v.1 this is my first attempt at the patch. It basically deals with the case when the user double-clicks on the tab header, which is not correctly handles bu the mouseUp method. Please note I hadn't changed the behavior of mouseUp, as it seems to be correct for all scenarios other than minimizing/maximizing a view with doubleClick.
Piotr, I've just tested your patch and it seems to work fine...thanks again !! I'm going to wait until 4.2.2 (SR2) goes out before applying it since I'm still working on 'hi pri' stuff, just wanted to let you know...;-).
Piotr's patch fixed the remaining issue. Fixed in master http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=e1a1fff989407054cf4e7ece964b90b66ce7b554
Verified in 4.3.0.I20130430-0031. Nice one...
