Community
Participate
Working Groups
After updating to 2020-09 (4.17) I cannot close an attached view. I have to detach it and close the standalone window. Neither there is a close x, nor I can closed it via wheel-click.
Rolf, I think we saw this earlier, IIRC this was caused by some stale data. Do you remember how this got fixed? Thanks Marvin for the report.
It is not each view btw. I can close class views. It's all these view like search, console, outline etc., that I can't close. I just saw this working on the exact same version for a colleague, who had a completely fresh workspace (and dark theme).
If you open a new (emptry) workspace do you see the close button?
(In reply to Lars Vogel from comment #3) > If you open a new (emptry) workspace do you see the close button? With a virgin workspace I see the close buttons. If I tell Eclipse to copy preferences when creating the new workspace, the buttons are missing.
The recent bug we fixed w.r.t. the closable state is Bug 433465. I don't remember another bug related to close behavior. Which perspective do you use? Can you attach the workbench.xmi file of the workspace that doesn't show the close buttons? (ws\.metadata\.plugins\org.eclipse.e4.workbench\workbench.xmi) Given the preference copy, my first hunch would be that it is caused by the PerspectiveBuilder that adds IPresentationEngine.NO_CLOSE tags.
Manually exporting preferences (all) and manually importing them does not produce the problem.
Created attachment 284143 [details] workbench.xmi
I use Java perspective, Debug and Synchronize. All show (or hide) the close button issue.
From the workbench.xmi file, closeable="true" is missing on most views. The search view and type hierarchy view should be closable. IPresentationEngine.NO_CLOSE is not found in the model, so should not make a difference. It should be investigated why the views are not marked closable. What was the last version of Eclipse where the close buttons do work?
I used that workspace with 2020-06 (4.16) before, which I updated from a freshly downloaded 2020-03 (4.15).
I found this in the file: ############## <descriptors xmi:id="_2S8cyvjFEeqH0oL0NgwCJQ" elementId="org.eclipse.search.ui.views.SearchView" label="Search" iconURI="platform:/plugin/org.eclipse.search/icons/full/eview16/searchres.png" tooltip="" allowMultiple="true" category="General" closeable="true" contributionURI="bundleclass://org.eclipse.ui.workbench/org.eclipse.ui.internal.e4.compatibility.CompatibilityView"> <persistedState key="originalCompatibilityViewClass" value="org.eclipse.search2.internal.ui.SearchView"/> <persistedState key="originalCompatibilityViewBundle" value="org.eclipse.search"/> <tags>View</tags> <tags>categoryTag:General</tags> </descriptors> ############## To me it looks like it is marked closeable. Or do I look at the wrong element?
(In reply to Marvin Fröhlich from comment #11) > To me it looks like it is marked closeable. Or do I look at the wrong > element? That is the descriptor, which states that it is closable. Also the shared instance MPart is marked closable, however, the closable flag is overridden in placeholders which do not have the closable state: <children xsi:type="basic:PartStack" xmi:id="_z521rvjAEeqUsOVTR6FWiw" elementId="org.eclipse.debug.internal.ui.ConsoleFolderView" containerData="5000" selectedElement="_z521r_jAEeqUsOVTR6FWiw"> <tags>newtablook</tags> <tags>org.eclipse.e4.secondaryDataStack</tags> <tags>Java</tags> <tags>General</tags> <children xsi:type="advanced:Placeholder" xmi:id="_z521r_jAEeqUsOVTR6FWiw" elementId="org.eclipse.ui.console.ConsoleView" ref="_z53dnPjAEeqUsOVTR6FWiw"/> <children xsi:type="advanced:Placeholder" xmi:id="_z521sPjAEeqUsOVTR6FWiw" elementId="org.eclipse.ui.views.TaskList" toBeRendered="false" ref="_z53dkPjAEeqUsOVTR6FWiw"/> <children xsi:type="advanced:Placeholder" xmi:id="_z521sfjAEeqUsOVTR6FWiw" elementId="org.eclipse.ui.views.BookmarkView" toBeRendered="false" ref="_z53ct_jAEeqUsOVTR6FWiw"/> <children xsi:type="advanced:Placeholder" xmi:id="_z521svjAEeqUsOVTR6FWiw" elementId="org.eclipse.ui.views.PropertySheet" toBeRendered="false" ref="_z53fYPjAEeqUsOVTR6FWiw"/> <children xsi:type="advanced:Placeholder" xmi:id="_z521s_jAEeqUsOVTR6FWiw" elementId="org.eclipse.jdt.debug.ui.DisplayView" toBeRendered="false" ref="_z53gHvjAEeqUsOVTR6FWiw"/> <children xsi:type="advanced:Placeholder" xmi:id="_z521tPjAEeqUsOVTR6FWiw" elementId="org.eclipse.search.SearchResultView" toBeRendered="false" ref="_z53gH_jAEeqUsOVTR6FWiw"/> <children xsi:type="advanced:Placeholder" xmi:id="_z521tfjAEeqUsOVTR6FWiw" elementId="org.eclipse.jdt.callhierarchy.view" toBeRendered="false" ref="_z53hbfjAEeqUsOVTR6FWiw"/> <children xsi:type="advanced:Placeholder" xmi:id="_z521tvjAEeqUsOVTR6FWiw" elementId="org.eclipse.search.ui.views.SearchView" toBeRendered="false" ref="_z53fEPjAEeqUsOVTR6FWiw" closeable="true"> <tags>View</tags> <tags>categoryTag:General</tags> </children>
I tried to add the closeable="true" attribute to that element manually. It didn't lead to the view being closeable. And Eclipse immediately removed that attribute from the element when loading the xmi. Is there anything else, I could try?
Can you start Eclipse with "-clearPersistedState"? This resets any ui customizing.
(In reply to Lars Vogel from comment #14) > Can you start Eclipse with "-clearPersistedState"? This resets any ui > customizing. Yes, I did this. And it reset my workspace to all defaults. Close buttons are there. I would like to avoid this step for my main workspace.
(In reply to Marvin Fröhlich from comment #13) > I tried to add the closeable="true" attribute to that element manually. It > didn't lead to the view being closeable. And Eclipse immediately removed > that attribute from the element when loading the xmi. > > Is there anything else, I could try? For the real hacker, you would add the closable attribute to each child with the type xsi:type="advanced:Placeholder", similarly to the SearchView already has. Be sure that Eclipse is closed. I would expect that the attribute would stay then.
(In reply to Rolf Theunissen from comment #16) > (In reply to Marvin Fröhlich from comment #13) > > I tried to add the closeable="true" attribute to that element manually. It > > didn't lead to the view being closeable. And Eclipse immediately removed > > that attribute from the element when loading the xmi. > > > > Is there anything else, I could try? > > For the real hacker, you would add the closable attribute to each child with > the type xsi:type="advanced:Placeholder", similarly to the SearchView > already has. Be sure that Eclipse is closed. I would expect that the > attribute would stay then. You should also be able to use the model spy to do this in a running Eclipse and close should stay active after restart. See spy section in https://www.vogella.com/tutorials/EclipseRCP/article.html#installation and use Ctrl+3 to open it after installation.
Btw. Creating a new workspace and copying "Layout" carries the misconfiguration with it. It's not preferences and of course not working sets. (In reply to Rolf Theunissen from comment #16) > For the real hacker, you would add the closable attribute to each child with > the type xsi:type="advanced:Placeholder", similarly to the SearchView > already has. Be sure that Eclipse is closed. I would expect that the > attribute would stay then. Yes, this helped. These views are closeable now. Will this bug be addressed at all, so that others don't run into that hassle? Or is it something, we have to live with? Let me give you a big thumbs up for your great effort. Thanks a lot.
And btw. I can confirm, that in another workspace of mine, that I frequently used with 2020-06 as well, the workspace xmi does not have these placeholder elements closeable, but still these views were very well closeable in the IDE. So, this must be some interpretation bug rather than a config migration thing.
(In reply to Marvin Fröhlich from comment #19) > And btw. I can confirm, that in another workspace of mine, that I frequently > used with 2020-06 as well, the workspace xmi does not have these placeholder > elements closeable, but still these views were very well closeable in the > IDE. > > So, this must be some interpretation bug rather than a config migration > thing. In fact, the interpretation was incorrect before 2020-09 that is fixed in Bug 433465. However apparently the value of this attribute is incorrectly set, and that is exposed now. I am not sure if we can trace down where that incorrect value originates from. I assume that you have migrated the settings over and over again. Do you have any clue on which Eclipse version you created the settings first? Could that have been on a Eclipse 3 version? (Given the workarounds available changing the criticality back to normal)
(In reply to Rolf Theunissen from comment #20) > I assume that you have migrated the settings over and over again. Yes. ;-) (In reply to Rolf Theunissen from comment #20) > Do you have any clue on which Eclipse version you created the settings first? Could that have been on a Eclipse 3 version? > Yes, definitely. These settings are very old. (In reply to Rolf Theunissen from comment #20) > (Given the workarounds available changing the criticality back to normal) I agree. For me this is ok now. I have fixed my workspaces. But I don't know, if we can expect from everyone to mess around with XML files like that. Well, in the end we're all developers, he? ;-)
I am confident that the incorrect value of the closeable atttribute originates from the migration from E3 to E4 perspective descriptions. Specificity, org.eclipse.ui.internal.e4.migration.PerspectiveBuilder#createPlaceHolder creates placeholders with the default value for the closable attribute (i.e. false). By now these kind of migrations are candidates for removal, only recent workspaces will correctly be migrated in newer version. So rather then fixing the migrator, we would remove it. What remains is the potential broken workspaces for (only a limited number of) users. @Lars, would it be worth the effort to try to build a migrator that fixes this issue in the model? It will only be released in 2020-12, so most users will already suffer from the issue before that is released. And I don't expect that the migrator is trivial, because it could have undesired side-effects (e.g. enabling close in products that had it explicitly disabled).
Well, maybe it doesn't hurt to create a fresh workspace every 10 years. :-) Thanks again for your help.
@Lars, would it be worth the effort to try to build a migrator that fixes this issue in the model? It will only be released in 2020-12, so most users will already suffer from the issue before that is released. And I don't expect that the migrator is trivial, because it could have undesired side-effects (e.g. enabling close in products that had it explicitly disabled). [tag] [reply] [−]Comment 23Marvin Fröhlich CLA Friend 2020-09-17 11:08:59 EDT IMHO,no, unless lots of users are affected.
Hi there, I'm facing the same error. Reading the thread, I'm not sure if there is a workaround or if there will be solved in the future. Could you please summarize it? Thanks
(In reply to Marc from comment #25) > Hi there, I'm facing the same error. Reading the thread, I'm not sure if > there is a workaround or if there will be solved in the future. Could you > please summarize it? > Thanks The closeable attribute is incorrectly set in the workspace model (workspace.xmi) when migrating from a E3 workspace to a E4 workspace, i.e. it is not set to true in that migration. So the error is introduced years ago but only recently results in problems due to proper handling of the attribute in the model now. Detecting that this problem exists and was introduced by the E3-E4 migration is difficult. Therefore its hard to make a model migrator in the general case. Making a script/plugin to fix this error should be doable. Workarounds: 1. start with "-clearPersistedState", this will remove the workspace model and reset all UI changes. 2a. set the closable attribute using the model-spy 2b. set the closable attribute in the workbench model by manually editing workspace.xmi (make sure u make backups) Reset perspective might work as well.
*** Bug 567312 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 574819 ***
