Default Location of Workspace - (bug 33976, 34532) Currently if the user doesn't specify the location of their workspace, then the default is to place is in a "workspace" directory under the Eclipse install directory. (equivalent of using "user.dir" java System property) This is very problematic, especially in the cases where you have a multi-user system and a single shared installation (like Linux) where users don't have write access to the installation directory. A better solution would be to use the user's home directory ("user.home" java System property) as a default location. This would result in (for instance) /usr/home/fred (on Linux) or C:/Documents and Settings/Fred (on Windows).

Separation of User Settings and Plug-in Metadata - (bug 36965) It is common for users to want to share some settings (like background colours and fonts) with all workspaces that they use with a particular Eclipse install, while other settings (like compiler settings) should be on a per workspace basis. Currently Eclipse all of these settings on a per workspace basis and we would like to remove this bundling.

Multiple Workspaces - (bug 37681, 5509) Users want to be able to better manage multiple workspace within the Eclipse environment. This could either mean coming up with a way to pretty a single Eclipse image running with 2 workspaces loaded, switching between multiple workspaces within the same session (via File -> Open/Close for instance), etc. Need to re-visit this for M5. Potential for some of this work to be done in the RCP work.

Translation of Executable Messages - (bug 35135) The messages which are displayed by the Eclipse executable are currently not translated. We need to define an external message story for this code, as well as the code which is in the startup.jar.

Show User Log File Location - (bug 33974) When there is an error trying to start Eclipse we produce a dialog to the user telling them to check their log file but we don't print out the exact location of this file. If the user specified the -data command-line argument then the location of the file is easy to calculate. Otherwise, it is done through Java System properties which is much harder to do in C code.

Improve Workspace/File-system Synchronization - (bug 36962) Improve workspace synchronization with file system. A file resource in the workspace gets out of sync when the underlying file in the file system is created, deleted, or rewritten outside of Eclipse. File resources usually remains out of sync until the user explicitly hits Refresh. The Eclipse Platform should provide ways to keep the in-memory representation in sync with the file system; for example, by hooking OS file system callbacks where available, and by polling for file system changes in a background thread.

Editing files outside of the workspace - (bug 37935) Allow editors to open files outside workspace. A common request is to be able to use Eclipse to open a file that is not part of the workspace, or perhaps even one on a remote system. In addition, applications would like to provide file extension associations so that double-clicking on a file in the OS desktop would open the associated Eclipse editor. The operations and capabilities available on these "outside of the workspace" files would need to be defined.

Notes: Users would like to be able to (for instance) double-click on a java file in Windows Explorer and open up Eclipse with that file so they can use the JDT/UI Java Editor. What people want: associate files, syntax-hightlighting and content assist. We could have a known project (e.g. "External Files") then you would be able to set up a classpath and project references for that project so you could get content assist, etc.