Community
Participate
Working Groups
Details are here http://www.eclipse.org/forums/index.php/t/399305/ The idea is that bringToTop doesn't focus (bring to top) a window when there are multiple windows around.
The fix here should be to have the WBWRenderer register a listener on SelectionChange and ensure the new 'top' window gets rendered / activated...
Created attachment 222512 [details] Proposed patch Eric can you have a look at this? I'm not sure on the setFocus or setActive part.
Comment on attachment 222512 [details] Proposed patch Sopot: you need to remove the listener in contextDisposed(). If you look at org.eclipse.ui.internal.SwitchToWindowMenu, it does the following: Shell windowShell = window.getShell(); if (windowShell.getMinimized()) { windowShell.setMinimized(false); } windowShell.setActive(); windowShell.moveAbove(null);
Thanks Brian. I'll prepare another patch as soon as I can.
*** Bug 338861 has been marked as a duplicate of this bug. ***
This is on top of my stack when I get back from EclipseCon, which is this weekend.
Created attachment 222937 [details] Proposed patch take 2
Setting a tentative 4.2.2. It's a relatively simple patch that takes no big time to test.
Sopot, 'bringToTop' should *not* bring that window to the top. Not sure how I ended up commenting as I did...that's what you'd have to do if someone specifically made the M[Trimmed]Window the MApplication's selected element. The reason falls out of the concept that 'bringToTop' doesn't change the active part (which is the difference between it and 'activate'). However bringing the window to the top would *require* changing the active part. If someone wants this behavior why not just use 'activate' or, if it's not a part then use bringToTop and then explicitly set the MApplication's selectedElement.
Eric this patch doesn't modify the bringToTop behavior. In the status quo, if someone sets the MApp's selected element to be a certain window nothing happens. This patch changes it to set that window as an active window. Regarding bringToTop's behavior there is this line: window.getParent().setSelectedElement(window); in the actual code (which I am not modifying) so the actual behavior *IS* that if a window is passed as an argument it will set the selected element of MApplication. So the fact is that doing bringToTop does set the selected element. The bug is not about what bringToTop does but that the renderer doesn't respond to what it does with the model. Or at least this is how we discussed it on IRC and what I got out from it.
Thanks Sopot, yes adding the listener is the right thing to do since synch'ing the model to the screen paramount. I'll have to change the current implementation of the ModelService though to remove the code that's setting the App's selected element in BTT.
You also have to update the bTT's Javadoc because it explicitly states that if you specify a TL window as a param it will be selected as the Apps selected window...
Actually on re-reading the J'doc I'd be satisfied if it works as currently described...does it (with your patch) ?
Yes. I don't touch bTT.
Defered to 4.3
Apologies...fell off my radar... http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=bef4ce9767b8076dd7a5fa8f468ac93ecbaa8ce0 Applies Sopot's patch...thanks Sopot !!
Marking fixed...
Sopot, any chance you could test this and mark it verified if it's working ?
Verified in I20130502-0800
Thanks Sopot !
