Community
Participate
Working Groups
Build F2 The following preferences were not transfered from one workspace to another using the export/import preferences feature. Workbench - Perform build automatically on resource startup Workbench>Editors - Key bindings Workbench>File Associations - Added/Removed types and editors - Default Workbench>Fonts - Banner font - Header font - Text font Workbench>Label Decorators - Selection of decorators Workbench>Local History - Days to keep files - Entries per file - Max file size Workbench>Perspectives - Default perspective Workbench>Search - Reuse editors - Emphasize inexact - Foreground color Workbench>Startup - not tested Build Order - Use default - order Debug>Console - Text font (see bug 19485) External Tools>Ant -Added classpath variables, tasks and types Help - Current web browser adapter not tested as there was only one Java>Classpath Variables - Added/Removed classpath variables Java>Debug - Debugger timeout Java>JUnit - Show the Junit results - Removed stack filter patterns Java>Templates - New, Edited, Removed Plug-In Devlopment>Source Code Location - Added, Removed Plug-In Devlopment>Target Platform - another compatible application - Application Location - Selection Team - Use Incoming/Outgoing Team>CVS>Console - Console fon setting (see bug 19483) Team>File Content - Add, Remove, Change Team>Ignored Resources - Add, Remove, Selected
Many of these are not stored in the preference store. E.g. autobuild is just in the workspace description. Others clearly should be, e.g. Debugger Timeout. Need to go through them all and consider whether they should be in the preference store. Mirroring state kept elsewhere (like autobuild) is a possibility, but there is a risk of them getting out of sync.
Java Debugger timeout preferences problem logged as bug 19541
Bumping up priority. Please file PRs against the other components and mark them as blocking this one.
For F3, can only address ones that are straightforward. Should avoid mirroring state that is kept elsewhere (e.g. local history settings).
Resolved for those in the Platform UI that are not too dangerous to change. Here is the breakdown. Works in build 20020610 Workbench>Fonts - Banner font - Header font - Text font Fixed and verified by RG Workbench>Editors - Key bindings Workbench>Label Decorators - Selection of decorators Workbench>Perspectives - Default perspective High risk fix - not done Workbench - Perform build automatically on resource startup Workbench>File Associations - Added/Removed types and editors - Default Workbench>Local History - Days to keep files - Entries per file - Max file size Build Order - Use default - order
Added Bug 19937 as a dependancy as this prevents import working for the Ant preference page.
Marking as later as all work for F3 (not including dependant PRs) has been done.
Should re-investigate for 2.1
Rather than the workbench attempting to mirror core settings as preferences, it would be better for core to move to using preferences for these settings (auto build, local history settings, etc.).
Filed bug 21977 for core to consider using preferences for workspace settings.
Now that Core is using the preference store for its own settings like autobuild, we should not have to mirror these ourselves.
Upping proirity to P3 and marking as normal.
Once we have access to the constants from Core we will also have to start listening to the build order preference and generating an auto build from that. I would suggest splitting WorkbenchPreferenceListener up and adding a CorePreferenceListener that generates global build actions for auto build and build order.
We should not be triggering builds ourselves. If the user changes the autobuild preference, that should change the setting in Core as it does now. Core should now set this in their preference store. Listeners on Core's preferences will be notified. In our own implementation, we will not have to fake out a preference notification for this as we do currently. We can just hook Core's.
We currently do this in two cases: when updating build order and when updating auto build. DJ if this OK I will remove both of our build actions that we create. This means our only concern will be adding and removing the build action button from the window when auto build is toggled.
*** Bug 21971 has been marked as a duplicate of this bug. ***
We will leave the build action behavior as it is as we do not want to trigger extra actions when the preferences are changed outside of the UI.
Closing PR as we have added all that we can for the UI.
Marking as closed.
