-
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 8 replies
-
|
The solution is to remove the workbench.xmi under |
Beta Was this translation helpful? Give feedback.
-
|
Even with always, the state of the UI widgets will be persisted in workbench.xmi. So if you add changes and want to make them visible you would need to close and reopen the view or delete the persisted state of the workbench. |
Beta Was this translation helpful? Give feedback.
-
A long standing issue. The state of the workbench (based on what the user did) is saved during shutdown (and time based). If the fragment is present, its current state will also be persisted and restored. The system cannot distinct between user changes and changes based on the contribution. The typical solution my client use for this is to write a model add-on which "does the right thing if needed". For example, I wrote a long time ago the ModelCleanupAddon which asynchronously searches for model contributions which are no longer present and removes them. For menu and toolbar contributions to the applicatoin you can use persistState=false as persistedState to indicate that the menu and toolbar should not be persisted. Something you cannot use for views as the user might move them around, duplicate or close them, etc. So I would agree that we have a bug but so far we also do not have a good idea how to implement this correctly. |
Beta Was this translation helpful? Give feedback.


@jdneo I more mean in the
plugin.xmlas there is an option to apply the fragment always or only initially:for me it looks like your fragment is only applied
initiallyornonexists