Community
Participate
Working Groups
We are using this construct which does not work in juno rcp: layout.createPlaceholderFolder(ID + ".folder.left", IPageLayout.LEFT, 0.3f, layout.getEditorArea()); //$NON-NLS-1$ layout.createPlaceholderFolder(ID + ".folder.left.bottom", IPageLayout.BOTTOM, 0.65f, ID + ".folder.left"); //$NON-NLS-1$ layout.createPlaceholderFolder(ID + ".folder.bottom", IPageLayout.BOTTOM, 0.65f, layout.getEditorArea()); //$NON-NLS-1$ What does work in juno is this layout.createPlaceholderFolder(ID + ".folder.left_top", IPageLayout.LEFT, 0.3f, layout.getEditorArea()); //$NON-NLS-1$ layout.createPlaceholderFolder(ID + ".folder.left_bottom", IPageLayout.BOTTOM, 0.65f, ID + ".folder.left_top"); //$NON-NLS-1$ layout.createPlaceholderFolder(ID + ".folder.bottom", IPageLayout.BOTTOM, 0.65f, layout.getEditorArea()); //$NON-NLS-1$
I'm sorry but that is probably not what is causing the problems. Even with the latter construct (which seemingly solved the problem in a different perspective) the views are not rendered. I believe now that it has to do with the rendering of the "left corner" placeholder that I am trying to create. If I open the live application model, I see that the placeholder construct is created correctly but that the "to be rendered" flag is off. The views are correcly placed in the stacks and if I flip the "to be rendered"flag of the partstack then the views become visible. If I change strategy and put the construct like so: layout.createPlaceholderFolder(ID + ".folder.left", IPageLayout.LEFT, 0.3f, layout.getEditorArea()); layout.createPlaceholderFolder(ID + ".folder.bottom", IPageLayout.BOTTOM, 0.65f, layout.getEditorArea()); layout.createPlaceholderFolder(ID + ".folder.corner", IPageLayout.LEFT, 0.3f, ID + ".folder.bottom"); apart from the not rendered flag the construct looks fine in the application model.
Created attachment 232034 [details] Effect of perspective layout.createPlaceholderFolder(ID + ".folder.left", IPageLayout.LEFT, 0.3f, layout.getEditorArea()); layout.createPlaceholderFolder(ID + ".folder.bottom", IPageLayout.BOTTOM, 0.65f, layout.getEditorAre layout.createPlaceholderFolder(ID + ".folder.corner", IPageLayout.BOTTOM, 0.65f, ID + ".folder.left"
Created attachment 232035 [details] Model state
(In reply to comment #3) > Created attachment 232035 [details] > Model state Can you point me to some classes you suspect? Then I will take a look.
Wim, none of your examples show the definition of any placeholder elements nor their referenced MParts...any chance you could append a more complete snippet ? It's not part of the normal rendering behavior to automatically make a parent's TBR true just because it has children with TBR true... My first thought was to use 'createFolder' rather than 'createPlaceholderFolder'. The difference should be that *this* folder is created with its TBR already == true. Note that you may be confused by the term 'placeholder' which in this case has absolutely no effect on how the views are placed (they'll always be accessed through MPlaceholders)...it's a leftover from 3.x where there were different concepts. If you were, for example creating a stack that shouldn't be initially shown then you'd use 'addPlaceholderFolder' but then the expectation would be that all its views were initially not to be shown; showing one of them would also make the stack visible.
(In reply to comment #5) Eric, to be complete, I am taking a legacy RCP and I am just running it unmodified. The legacy RCP uses the perspectivefactory class to define the initial layout with placeholderfolder. AFAIK a valid and well know pattern. Finally, it is using perspectiveextensions to submit views into place. The result is that the views are invisible in 4.x but the views are visible in 3.x IMHO, when the compat layer runs the perspectivefactory then the resulting partstack should indeed have TBR:false, however, as soon as a view is placed according to the perspectiveextension then the partstack should be made visible.
Created attachment 232072 [details] Complete RCP app that demonstrates the problem Please run it and you will see that there is only one view visible. This view is placed in a placeholderfolder called "..bottom". There are two other placeholderfolders to the left of this view. These are relative to each other and are rendered as a partstack however, the flag TBR is false which gives the wrong result. Please add the live model editor to the run config to see the resulting model.
Wim, got it...you're almost certainly correct and thanks for the analysis. We need something like the inverse of the cleanup addon that, once all perspectives have been fully defined resets the TBR on any stacks that actually contain TBR 'true' entries (and or resets the TBR as part of the 'addView' code). I've tagged this for the SR1 release since it's a regression against 3.x...
Moving to major since it will fail to render unmodified existing RCP applications when they are using the layout.createPlaceHolderFolder method in the perspective class.
A workaround is to replace PlaceholderFolder with Folder. In 4.x using Folder has the same effect as PlaceholderFolder in 3.x. Unfortunately simply replacing Placeholderfolder with Folder gives problems in 3.x. So to remain compatible, code like this must be used in the IPerspectiveFactory Class: // Pseudo code String version = Platform.getBundle(Platform.PI_RUNTIME).getHeaders().get("Bundle-Version"); if (version < ("3.8.0")) { layout.createPlaceholderFolder ... } else { layout.createFolder ... }
The patch proposal has been sent to Gerrit: https://git.eclipse.org/r/#/c/18561/ thanks, Daniel
Switching milestone to 4.4M4 since the Gerrit patch was against master... Daniel, I tested your patch but found that it was making stacks that should not be visible show up. When going over the defect I noticed that there was a particular pattern being used; the placeholder stacks were added using the perspective factory but the views were being added using perspectiveExtensions. The actual bug seems to be that while the view *and its stack* are both TBR true the stack's parent sash container's TBR was false... Turns out that 'addView' (via 'insert') has code that walks up the model setting TBR to true for *all* parents of the newly added view (line 597). The corresponding code to parse the perspectiveExtensions calls 'stackView' (in PerspectiveExtensionReader) and this code was lacking the same 'set TBR to true' pattern. I've tried the fix above locally and it works but perhaps you can find a way to re-use the 'insert' method from within 'stackView' which would clean up the code *and* fix the defect ?
(In reply to Eric Moffatt from comment #12) > Switching milestone to 4.4M4 since the Gerrit patch was against master... > > Daniel, I tested your patch but found that it was making stacks that should > not be visible show up. When going over the defect I noticed that there was > a particular pattern being used; the placeholder stacks were added using the > perspective factory but the views were being added using > perspectiveExtensions. > > The actual bug seems to be that while the view *and its stack* are both TBR > true the stack's parent sash container's TBR was false... > > Turns out that 'addView' (via 'insert') has code that walks up the model > setting TBR to true for *all* parents of the newly added view (line 597). > The corresponding code to parse the perspectiveExtensions calls 'stackView' > (in PerspectiveExtensionReader) and this code was lacking the same 'set TBR > to true' pattern. > > I've tried the fix above locally and it works but perhaps you can find a way > to re-use the 'insert' method from within 'stackView' which would clean up > the code *and* fix the defect ? Could you please give the usecase where the patch does not work? I'm going to verify the next version of patch using it Daniel
New version of patch has been submitted to Gerrit Daniel
Eric, there's a new patch on https://git.eclipse.org/r/#/c/18561/ to be reviewed. PW
Daniel, sorry for the delay. See bug 409834. There's a project on here that provides two perspectives A & B which initially open with just the editor area showing and has a toolbar button to open a view. When I applied your initial patch I noticed that the perspectives were now initially showing empty stacks, not hidden as expected... I'll review the new patch, thanks... (a quick glance looks good)
Pushed (on Daniel's behalf): http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=cf38dbb74abf87a193b4754b0274410dc105934e
Verified in the build: I20131209-2000 Daniel
(In reply to Daniel Rolka from comment #18) > Verified in the build: I20131209-2000 > Thanks guys. Much appreciated.
