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.

Notes: We need to improve the case where people are editing files
outside of Eclipse and we detect that the files in the user's workspace
are out of sync with the file system. A good general statement is "it
is hard to use Eclipse when the files are not in sync". Currently there
exists the auto-refresh plug-in which users can download and install. We
need to look at integrating this into the SDK. There are legal issues for
this as well as technical issues. First step might be to do a package rename
and start to include it in the build, with future work including integrating
it better into the base plug-ins.

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.