[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-core-dev] Re: IResource outside the workspace
|
Comments below.
John Arthorne wrote:
It keeps us employed, alternately removing and adding bitterness with
each release ;)
I was sure there was a good reason. ;-}
True. In fact, metadata wasn't stored in the project folder in Eclipse
1.0. However, people wanted it there so that when the project was
transferred to another workspace, either via repository or zipping and
emailing to a friend, it wouldn't be lost and require recreating.
Here's the design doc that proposed the change:
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core-home/documents/rfc/0006/index.html
I certainly understand the use case. It would have been nice to retain
the option. (If you tell me you did, I'm _really_ going to be
embarrassed. But I'd love to hear it!)
> The current workspace serves two functions; it is used to store metadata
> for a collection of projects and it is used as the root folder for
> projects. The latter is an unnecessary restriction. The location of
> project folders is part of the metadata.
The latter isn't even a restriction. If you don't choose your own
location in the project wizard, the workspace location is just used as
the default. However, you have always been able to store each project
in a different location on disk, separate from other metadata, if
desired. There is a danger of confusing the "workspace" directory on
disk with the IWorkspace and IResource API. The "workspace" directory
is actually defined by the base Eclipse runtime (which calls it the
"platform instance data area" just to add confusion), and its default
name is more of an historical artifact.
Ok, got me there. I knew you could link to projects but I really thought
they had to be in some workspace. It's a little unnatural to make a
folder visible/usable by creating a new project, and when you do it
metadata gets scribbled in your folder, but it does work. I didn't know
that. Always, you say?
> I can't quite see the picture that Ed has in his mind. If it's a
> Navigator view with C, D, E and F drives at the top level, I don't agree
> with it. An IDE needs to focus. Users really don't want you to search
> their entire file systems. If, however, it's a view containing
> user-selected folders that they have chosen to designate as projects of
> one type or another (or multiple types), that sounds about right to me.
This also roughly sounds like what we have now...
Yes, darn it, it does. ;-}
When the split was made between RCP and IDE portions of the platform,
IResource was actually explicitly chosen as the dividing line. Many RCP
apps don't have any user files that they operate on. Those that do
often don't need things like projects, builders, markers, and other
IDE-like concepts attached to IResource. And if they want that stuff,
they can always add org.eclipse.core.resources to an RCP app. I must
admit that by throwing RCP into the conversation you've lost me about
what the "real problem" is...
The reason for bringing RCP into the conversation is because many RCP
applications _do_ use files and many would like to use features that
depend on using files but have nothing to do with an IDE, like editors
with markers and annotations. (For the life of me I don't see why
markers are an IDE-related concept.) In my experience, you can't just
add these things to an RCP app and expect them to work. You have to
bring the IDE along with them.
I may have over-generalized the Eclipse issues, but there are some yet.
Save As external file. Double-click to open from desktop. All subjects
of individual bug reports, but all file-related operations outside a
workspace.
Bob
