Community
Participate
Working Groups
Build Identifier: When creating new workpace and copying working set some settings is not copied If I select File->Switch Workspace->Other and creates a new workspace I canalso check "Copy settings->Workspace Layout". Many things are copied, but I have noticed a few settings that I loose: * In Ctrl+H Serach: Visible tabs (after using Customized) and file name patterns of filename (*.java, *.xml ...) * "Wrap search" in Ctrl+F and previously launched (Fixed in Helios) * Question "Always save resources before launching" forgets that I said checked "Remember my descision" * Prompt on exit Eclipse is back, and also forgets that I said checked "Remember my descision" * Also "Remember my descision" about associated perspectives is lost Reproducible: Always
(In reply to comment #0) > * "Wrap search" in Ctrl+F and previously launched (Fixed in Helios) This one is OK. But the four others is still broken.
(In reply to comment #0) > * In Ctrl+H Serach: Visible tabs (after using Customized) and file name > patterns of filename (*.java, *.xml ...) I don't think this setting is intended to be copied through the "Copy settings->Workspace Layout" option. This should be controlled via workspace\.metadata\.plugins\org.eclipse.jdt.ui\ .Not sure if copying workspace layout also copies jdt/ui settings stored here. Moving to Platform/UI for comment.
I believe any feature that wants to allow this must use the org.eclipse.ui.preferenceTransfer extension point so their preferences can be copied across properly. PW
The implication is that the provider of each preference you would like copied needs to have a bug. you can move these back to Platform/UI: * Prompt on exit Eclipse is back, and also forgets that I said checked "Remember my descision" * Also "Remember my descision" about associated perspectives is lost and open bugs about the other ones (not platform UI or IDE). PW
(In reply to comment #4) > The implication is that the provider of each preference you would like copied > needs to have a bug. Opened bugs 318593 and 318592 corresponding to points 1 and 3, respectively. Moving back to Platform/UI for points 4 and 5.
>I believe any feature that wants to allow this must use the >org.eclipse.ui.preferenceTransfer extension point so their preferences can be >copied across properly. As you can see in the switch dialog, Platform UI only offers 'Workbench Layout' and 'Working Sets'. I can't find any of those categories when using export or import which is based on preferenceTransfer. Hence I would assume that either only layout and working sets can be copied or the platform offers a mechanism (API or extension point) where clients can add additional stuff. >Opened bugs 318593 and 318592 corresponding to points 1 and 3, respectively. These bugs don't seem related.
(In reply to comment #6) > >I believe any feature that wants to allow this must use the > >org.eclipse.ui.preferenceTransfer extension point so their preferences can be > >copied across properly. > As you can see in the switch dialog, Platform UI only offers 'Workbench Layout' > and 'Working Sets'. I can't find any of those categories when using export or > import which is based on preferenceTransfer. It's the org.eclipse.ui.preferenceTransfer/settingsTransfer element (different from transfer which is used in the preferences import/export). PW
>It's the org.eclipse.ui.preferenceTransfer/settingsTransfer element (different >from transfer which is used in the preferences import/export). Ah I see. Thanks for the education. I think comment 1 is wrong i.e. I can't see that Find/Replace settings are honored and it would be wrong if that's the case. Also, preferences are not transferred either - again expected.
OK, it's actually different than I thought. Switch workspace is only providing "Transfer settings". Things like the layout (workbench.xml) and workingsets (workingsets.xml) are examples, and settingsTransfer is the mechanism that allows a plugin to export the data it keeps in its plugin state location to another workspace. There's no mechanism currently that includes preferences from switch locations. The correct place to add them would be org.eclipse.ui.internal.ide.ChooseWorkspaceWithSettingsDialog. Presumably the PreferenceTransferManager.getPreferenceTransfers() could be added to the settings check boxes, and added to the processing. But the settings transfers are execute from the old eclipse. AFAICT we would want the settings transfer to create the transfered preferences in their correct location at <newWorkspace>/.metadata/.plugins/org.eclipse.core.runtime/.settings which executing an Import in the new eclipse will do correctly. I'm moving this to 3.8 PW
I think there are two issues here: 1) preferences (see WONTFIX bug 132733) 2) dialog settings (this bug) For 1) me might be able to reuse the preference transfers we already have for import/export.
(In reply to comment #10) > I think there are two issues here: > 1) preferences (see WONTFIX bug 132733) > 2) dialog settings (this bug) > > For 1) me might be able to reuse the preference transfers we already have for > import/export. We view this as an important feature for our commercial product. Perspective customizations should also be transferable.
Do to resource constraints, we won't be looking at this for 3.8. Patches are welcome however. http://wiki.eclipse.org/Platform_UI/How_to_Contribute PW
(In reply to comment #12) > Do to resource constraints, we won't be looking at this for 3.8. Patches are > welcome however. > > http://wiki.eclipse.org/Platform_UI/How_to_Contribute > > PW Fair enough. "Put up or shut up" is the mantra for much of open source, and is a reasonable, an even expected, response. I'll try to get the time and go-ahead to pursue this and contribute the solution if I do.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
