[platform-core-dev] Re: IResource outside the workspace

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

Some responses below...


Ed Burnette wrote on 28/07/2005 11:04:29 AM:

> Bob's suggestion is not an alternative, it's a kludgy workaround.
> Imagine a web browser that only let you visit pages at known sites.
> To browse to another site you have to add a link to that site to 
> your "network neighborhood". This would let you set bookmarks
on 
> pages in that site, print pages, look at the html source, email 
> pages to other people, etc.. Would anybody accept such a browser?
> No, of course not.
>  
> Rather than focus on the technical difficulties,
look at the 
> benefits from the user's point of view. Some of the difficulties you
> cite would not occur in practice because you could make acceptable
> simplifying assumptions. Functionality should follow user needs not
> technical dictates. 

Functionality is always constrained by technical limits.
 The hardware, the virtual machine, and the operating system all impose
limits that we work under. I agree this shouldn't limit one's imagination
about what the ideal solution would be, but eventually the concrete solutions
must live within techical (and other) constraints.

> Otherwise we never would have had things like,
> say, refactoring, because they're extremely hard to implement and
> the user could just use global substitutions and cut and paste 
> anyway to do the same thing, right?

Refactoring can't be achieved with simple global search/replace;
it relies on the extensive metadata that is maintained in memory and on
disk. Refactorings operate within a well defined scope.

> Just like there is a CVS repository navigator
there should be a file
> system navigator. It would be intuitive to me if the Resource 
> Navigator view were used for that, but it could be something new.
> Folders which are "under Eclipse control", i.e., are Eclipse
> projects would have a special icon. It should be easy to add and 
> remove "Eclipse control" from a folder. It should be easy
to filter 
> what is shown in the view so that only the interesting things are
> shown. A few Eclipse IDE operations would naturally only be 
> supported in folders which are under Eclipse control.

This sounds like the kludge mentioned above, where
an explicit user action is required to associate and dissociate file system
entries with the Eclipse workspace.  What you describe is really a
stream-lining of the current new/import/export wizards.  For example,
today you can open an editor on an external file or a new file that does
not belong to any project.  To go from that single file to building
the scaffolding of a project in the workspace requires the user to perform
several disjoint steps:

1) File > New Project
2) Pick the kind of project it will be (and live to
regret it, because it's nearly impossible to change later)
3) Choose to create the project at an existing location.
Click Browse and find the project root.

The UI could offer (or the user could at some point
decide) to turn that open file into a project. It may be able to infer
the project type from the file extension, and make a reasonable guess at
the project's root directory.  A wizard or property page could be
used later on to further configure or add additional capabilities to the
project as needed (see recent discussion in platform-ui-dev).

> The ultimate goal is that the Eclipse IDE should
be self sufficient.
> I should never be forced to open the Windows explorer, or forced to
> use another editor like Textpad unless that's just my personal 
> preference. Everything that a tools user needs to do, everything 
> they need to search, all the files they need to look at or modify,
> should be at their fingertips inside the IDE. This was the beauty
of
> Emacs, and in many ways I see Eclipse as the modern successor to Emacs.

This may be personal preference, but I have to disagree.
 A single application that does everything isn't likely to do everything
well.  I use external web browsers, a mail program, command shells,
and other applications and don't feel the need to put them all in one window.
 These applications are still very much at my fingertips through the
OS window manager or command shell.

John