Community
Participate
Working Groups
M2: I'm seeing quite a few windows that go grey, where M1 didn't (although I recall similar phenomena before Kepler). e.g. Type Hierarchy, Console, JUnit The grey windows stay grey after switching windows but generally restore after switching perspectives. I'm also seeing windows that have different shapes in different perspectives fail to switch to the shaping for the current perspective. Particular common but not reproducible when JUnit is in both Debug and Java perspectives. This too seems like a regression to pre-Kepler. I presume that trimming erroneous activations is also trimming required re-layouts.
Could you attach a screenshot that presents such grey windows?
This is related to the work Eric did on Bug 416650 I see this sometimes as well on linux PW
Created attachment 236328 [details] Example bad layout Attached shows more interesting features. Specifically the Variables View is shown in the Java perspective sized to fit its usage in the Debug perspective. More oddly, why is the Variables View, Debug and Breakpoints in the Java perspective at all? NB this is a Workspace that has evolved from Kepler and advanced and retarded a few times as bad evolution has been retyracted.
looks like a reparenting needs to trigger a layout-pass
This should get fixed for M3, hopefully via bug 416650.
(In reply to Thomas Schindl from comment #4) > looks like a reparenting needs to trigger a layout-pass No. It's not reproducible. Looks like you need to solve a concurrency issue and maybe many other funnies will suddenly be cured too.
(In reply to Thomas Schindl from comment #4) > looks like a reparenting needs to trigger a layout-pass In the case of JUnit, I may have a vertical orientation for one perspective and a horizontal for another. The View is therefore not shared between perspectives; just the displayed information content.
Created attachment 236345 [details] A grey Console View The grey Console View remained grey after one change of perspective, but recovered after a second.
Ed, I suspect that you actually are sharing the JUnit view. IIRC the horizontal / vertical alignment is based on the view's area isn't it. Is this just a Linux issue ? I saw one version of this on Windows which I fixed, perhaps there's another one specific for Linux? Paul, chan you show me this when you come back ?
(In reply to Eric Moffatt from comment #9) > Ed, I suspect that you actually are sharing the JUnit view. IIRC the > horizontal / vertical alignment is based on the view's area isn't it. I mentioned JUnit hori/vertyical to make a design point. In MVC parlance, the JUnit results are M and shared. The V is distinct for eaxch perspective. The C can be shared too. I just tried switching a JUnit from H to V in one perspective and indeed another perspective changed too, despite being a very bad fit. Do you want another bug for this?
Ed, just tried the scenario in your last comment and on my Win7 box I get the expected result. I had the JUnit view open in two perspectives in stacks where it was vertical in one and horizontal in the other. Switching perspectives always picks the alignment that matches the JUnit's aspect ratio. This is the expected behavior, not a defect. Also, it's the JUnit view's implementation that catches its size change events and resets the orientation not the platform. BTW, are there any of the artifacts you talk about still reproducible ? If not then we should look at closing this bug out. If it's a Linux issue I'll talk to Paul and we'll take a look.
JUnit has three modes; horizontal/vertical/auto. These problems are nothing to do with JUnit's auto mode. Perhaps we need a separate bug that setting JUnit vertical in one perspective conflicts with setting it horizontal in a nother. This bug is a very simple problem that occurs on many views that when changing perspective; the view in one perspective retains the layout of a previous perspective and sometimes gets a 'grey' window layout.
See also bug 420126 which fixed at least one scenario.
Ed, if you're on Linux then the mis-orientation of the JUnit view is likely caused by a failure to correctly size the part to its container in the newly showing perspective. Does a resize (i.e. dragging the sash or sizing the window) restore everything to its correct state ?
(In reply to Eric Moffatt from comment #14) > Ed, if you're on Linux I'm on Windows Vista
M4 is done...
Any chance of some priority on this regression? I'm getting really fed up wuith having to do spurious perspective changes to get JUnit/Console/GIT Staging windows laid out credibly.
(In reply to Ed Willink from comment #17) > I'm getting really fed up wuith having to do spurious perspective changes to > get JUnit/Console/GIT Staging windows laid out credibly. Much easier workaround is to fractionally resize any view.
Unless someone can attach steps to reliably reproduce this effect I'm going to have to close this defect as 'Yeti Sighting'... Paul, I've seen a layout issue on Linux...do you know how to reproduce it ?
(In reply to Eric Moffatt from comment #19) > Unless someone can attach steps to reliably reproduce this effect I'm going > to have to close this defect as 'Yeti Sighting'... > > Paul, I've seen a layout issue on Linux...do you know how to reproduce it ? Firstly ignore all comments about JUnit View above; they seem to cause confusion. Basically I get a mal-laid out view on perhaps 1 in 20 changes of view/perspective (not editor). Certainly involves my favourite views; Console, Git Staging, Type Hierarchy. The problem is almost ceratinly aggarvated by the re-use of views in more than one perspective, so what I often see is a view 'sensibly' laid out for the bounds in another perspective.
The sizing issues have been fixed against another defect... *** This bug has been marked as a duplicate of bug 426013 ***
