Bug 329580

Comment 1 Remy Suen 2010-11-05 15:01:39 EDT

Created attachment 182514 [details]
ModeledPageLayout patch v1

No magic required as we now actually have an MArea. We can just tweak the TBR flag of the area's placeholder element when we create the perspective.

Comment 2 Remy Suen 2010-11-05 15:02:47 EDT

(In reply to comment #1)
> Created an attachment (id=182514) [details]
> ModeledPageLayout patch v1

Fix released to CVS HEAD.

Thanks for finding this, Thomas! Do let us know if you see other differences between the 3.x and 4.x SDKs.

Comment 3 Thomas Kratz 2010-12-18 09:34:00 EST

Hi Remy,
This is my experience by now:
If a have an perspective with a visible editorArea open, open an editor inside and then open a perspective with the editorArea invisible the editor is still shown. if I reset the perspective manually the editor is hidden,

Comment 4 Remy Suen 2010-12-18 09:41:28 EST

(In reply to comment #3)
> If a have an perspective with a visible editorArea open, open an editor inside
> and then open a perspective with the editorArea invisible the editor is still
> shown. if I reset the perspective manually the editor is hidden,

Thomas, I cannot reproduce this problem. :/

1. I start my inner.
2. I open a file in the 'Java' perspective.
3. I then switch perspectives.
4. I only see the 'Problems' view.

public void createInitialLayout(IPageLayout factory) {
  factory.addView(IPageLayout.ID_PROBLEM_VIEW, IPageLayout.LEFT, 0.5f,
      factory.getEditorArea());
  factory.setEditorAreaVisible(false);
}

Does this work for you? I'm guessing not. :|

Comment 5 Thomas Kratz 2010-12-18 11:47:46 EST

No definitifely not. It appear like that at first the perspective is rendered correct and then its redrawn with the editor.

Comment 6 Thomas Kratz 2010-12-18 11:49:25 EST

at my side the single view is contributed as standalone through xml

Comment 7 Remy Suen 2010-12-19 12:27:28 EST

(In reply to comment #6)
> at my side the single view is contributed as standalone through xml

Okay, so your perspective code is just one line, yes?

public void createInitialLayout(IPageLayout factory) {
  factory.setEditorAreaVisible(false);
}

And then you have _one_ standalone view contributed through the perspectiveExtensions extension point, correct? Can you attach the XML snippet? Thanks.

Comment 8 Thomas Kratz 2010-12-20 03:18:03 EST

Created attachment 185517 [details]
perspective extension snippet

added my perspective extension. and yes my perpective factory is just this single line

Comment 9 Remy Suen 2010-12-20 12:18:03 EST

Unfortunately, I still cannot reproduce the problem. :/

Can you try stepping into the code to make sure that the placeholder's 'toBeRendered' feature gets set to 'false'? This should happen when you call setEditorAreaVisible(false).

After that, can you try to use breakpoints to see who is making it go back to 'true'? Thanks.

Comment 10 Thomas Kratz 2010-12-21 09:52:14 EST

Created attachment 185637 [details]
This is where it gets set visible again

I guess this is the point where it gets reactivated

Comment 11 Thomas Kratz 2010-12-21 09:54:10 EST

element at this point is
org.eclipse.e4.ui.model.application.ui.advanced.impl.PlaceholderImpl@4671b856 (elementId: org.eclipse.ui.editorss, tags: null) (widget: null, renderer: null, toBeRendered: false, onTop: false, visible: true, containerData: 5000, accessibilityPhrase: null)

Comment 12 Remy Suen 2010-12-21 09:57:02 EST

(In reply to comment #10)
> Created an attachment (id=185637) [details]
> This is where it gets set visible again
> 
> I guess this is the point where it gets reactivated

Thomas, is the part that it's trying to activate the editor that you had previously opened in the first perspective?

Comment 13 Thomas Kratz 2010-12-21 10:14:19 EST

The MUIElement in bringToTop is in fact my editor.
org.eclipse.e4.ui.model.application.ui.basic.impl.PartImpl@7792a63a (elementId: org.eclipse.e4.ui.compatibility.editor, tags: [removeOnHide, Editor]) (contributionURI: platform:/plugin/org.eclipse.ui.workbench/org.eclipse.ui.internal.e4.compatibility.CompatibilityEditor, object: org.eclipse.ui.internal.e4.compatibility.CompatibilityEditor@4007ab03) .....

Comment 14 Remy Suen 2010-12-21 10:15:59 EST

(In reply to comment #13)
> The MUIElement in bringToTop is in fact my editor.

Okay, so in your first perspective, do you have other parts there? If your active part is _not_ the editor and you switch perspectives, do you still get the same problem? I'm wondering if the cause is because it's trying to preserve the active part across the perspective switch.

Comment 15 Thomas Kratz 2010-12-21 10:19:21 EST

Hi Remy, i guess this is it. if I activate another view and switch perspectives everything is fine. It's only when the editor is active.

Comment 16 Remy Suen 2010-12-21 10:26:01 EST

(In reply to comment #15)
> Hi Remy, i guess this is it. if I activate another view and switch perspectives
> everything is fine. It's only when the editor is active.

Thanks for the information, Thomas. I am still trying to reproduce the problem but at least the problem is understood.

How do you switch perspectives? Do you use Ctrl+F8? Are you using Window > Open Perspective... > XXX? Or do you use Window > Open Perspective... > Other...? Or do you just click on the other perspective in the perspective switcher in the top right hand corner? I would like some information here because one way is "immediate" while the other one brings a shell up in front of the user and that causes additional SWT.Activate events between the different shells (the dialog and the original workbench window).

Comment 17 Thomas Kratz 2010-12-21 13:03:29 EST

I used the switcher that opens the open perspective dialog immediately.

Comment 18 Remy Suen 2010-12-21 17:56:01 EST

At this point I think the reason I can't reproduce the problem is because I'm testing on Linux/gtk+ and you're on Windows.

Comment 19 Thomas Kratz 2010-12-22 04:43:38 EST

Do you think theres a chance we get this fixed in the next couple of weeks ?

Comment 20 Remy Suen 2010-12-22 07:36:56 EST

(In reply to comment #19)
> Do you think theres a chance we get this fixed in the next couple of weeks ?

Assuming I understand the problem correctly (I can't say 100% for sure because I can't reproduce the problem), then yes, I don't see this being a complicated issue to resolve.

Please see bug 333081. I have attached a proof-of-concept patch there (to verify my suspicions on the cause of the bug). We can continue our discussions there.