Community
Participate
Working Groups
Created attachment 242685 [details] Perspective2 screenshot Setup: * Pick two perspectives (eg, Debug and Java) to use for testing. "Perspective1" and "Perspective2" * Switch to "Perspective1" ** Ensure the Console view is visible inside the View Panel * Switch to "Perspective2" ** Move the console view out of the View Panel (I have it on a second monitor, but just making it a separate window seems to suffice) Steps to Reproduce # Start in "Perspective1" ## Somehow make some console output - eg, run a simple app that outputs to the console # Switch to "Perspective2" ## What I see when doing this is the external Console view is clipped at a height of about 50% of the actual Console view height. # Resize the Console view ## Now the Console view is properly "expanded" inside the external view This, to me, looks like a "refresh/revalidate" UI bug that is common in Java Swing where if you have to pack/refresh/revalidate/layout/whatever the UI component for it to resize properly Screenshot attached
Created attachment 242686 [details] Perspective1 screenshot
Reproduced in I20140501-0200 on Windows 7 x64.
I've been seeing this recently as well, likely due to some of our layout 'optimizations'. We should take a look into this one. I see it mostly when I have the Console minimized in two different perspectives in 'fly outs' of different sizes. Starting a debug session always spews a lot of output for me because I have the test code in my WS. In my case the stack the console is in is minimized but opens quite wide in the Debug perspective but normal sized in my Java perspective. If I run my inner and from the Debug perspective, let the Console show up and quickly switch to the Java perspective I can get it into this state....
BTW, I'm almost certain that this is a regression from Kepler...
Here's the Gerrit: https://git.eclipse.org/r/26229 NOTE: this code will look odd because it arbitrarily resizes the CTF during the open. If we have two perspectives A & B both with the Console minimized and then when we open it in A we reparent the Console to A's CTF then show it. However since the CTF is the same size it was last time SWT treats this as a no-op; since the CTF didn't really change size it decides that it doesn't need to resize the selected tab's control (not realizing that the *same* control was just resized by showing the Console in B). This is only an issue when the Console is currently the selected element in *both* CTF's; if not the the change in the selected tab forces the correct size for the newly showing tab. BTW, for some unknown reason even trying to set the bounds of the tab item's Control to the CTF's client area didn't work (possibly because we're trapped in 'deferred layouts' at the time). Note that resizing the CTF will layout *only* the currently selected tab's control.
Released as http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=04a14605b883752859938c0c874af7efc3e3487e PW
Verified in 4.4.0.I20140515-1230. NOTE: I may have a better fix for this for 4.5. Rather than resizing the CTF (which should be considered the hack of last resort...;-) we should look at the ElementReferenceRenderer; it's responsible for the re-parenting so it's the right place to ensure that a control being re-parented into a CTF has the correct bounds...
Note that we're currently considering using a pattern that rather than relying on the CTF's 'layout' when dealing with issues around the *item* control size it may be better to simply use the following pattern: cti.getControl().setBounds(ctf.getClientArea()); This will simply adjust the item's bounds and an internal layout will be automatically triggered if the bounds actually change (as they would not if you were just switching tabs).
