Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-core-dev] Re: IResource outside the workspace 
Ed Burnette wrote:
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.
Ridiculous analogy. And it's not my "suggestion". You're a hard guy to agree with! ;-}
But I do agree. People (who don't have a Smalltalk background) want to use files in the file system. They don't want any restrictions about where those files are. They don't want products filling up their folders with metadata, refusing to work except on "blessed" folders, telling them where they can create folders, or any of the other restrictions Eclipse has.
Yes, Eclipse is wildly popular. People will take the bitter with the sweet. But why leave the bitter in if it's not necessary to solve the problem?
A project is just a folder with some associated metadata. It doesn't need to be in a special location. The metadata doesn't need to be stored in the project folder.
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.
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.
To respond to this requirement, Eclipse is slowly eking out little tweaks that liberalize file system access. Linked projects, folders, files. File > Open File. But these little changes are either too small to make much practical difference or, as in the case of Open File, leave broken API and dangling end cases in their wake. IResource now stands as the great divide between Eclipse-based products and RCP. Maybe it's time to go after the real problem. 

Bob
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. 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? 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. 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. 
    ------------------------------------------------------------------------
    *From:* platform-core-dev-bounces@xxxxxxxxxxx
    [mailto:platform-core-dev-bounces@xxxxxxxxxxx] *On Behalf Of *John
    Arthorne
    *Sent:* Wednesday, July 27, 2005 4:30 PM
    *To:* Eclipse Platform Core component developers list.
    *Subject:* [platform-core-dev] Re: IResource outside the workspace


    (I have retitled the thread because pulling resources out of the
    workspace is really quite unrelated to the original discussion of
    putting logical things *into* the workspace.)

    My belief is that this is a thread that quickly unravels.  Would an
    IFile outside the workspace appear in the resource navigator? If
    not, how would one browse and find one? Would a resource visitor
    find it?  Would resource change events be broadcast for it?
     Presumably if it's a *.java file I will want to compile it.  Would
    I be able to put the IFile under version control with CVS or another
    repository?  All of this functionality requires assembling and
    maintaining lots of metadata, which requires a life-cycle that
    allows us to know when to start collecting that data and when it can
    be thrown away. Maintaining this meta-data for your entire hard disk
    would not be practical.  I understand that having a strict notion of
    what's in the workspace seems cumbersome, but I think it's a
    critical prerequisite to all the IDE bells and whistles that come
    along with IResource. If one doesn't want all the bells and
    whistles, it becomes a difficult slicing game to determine what
    functionality makes sense on "reduced" external resources.

    The alternative you suggest, on the other hand, is more tenable.
     It's been possible since 2.1 to link arbitrary files and folders
    into some project.  With this approach the association of the
    resource with the workspace, and the lifecycle of the accompanying
    metadata, is well defined.  As you say, this gives you most of the
    IResource-based functionality "for free".

    John




    *Bob Foster <bob@xxxxxxxxxx>*
    Sent by: platform-core-dev-bounces@xxxxxxxxxxx

    27/07/2005 03:01 PM
    Please respond to
    "Eclipse Platform Core component developers list."


    	
    To
    	"Eclipse Platform Core component developers list."
    <platform-core-dev@xxxxxxxxxxx>
    cc
    	
    Subject
    	Re: [platform-core-dev] Re: IFile that corresponds to a logical view.


    	





    That would certainly be one way out of the current split that divides
    editor support in half, makes annotations unavailable to RCP, etc. Pull
    resources out of the workspace (and out of the IDE).

    An alternative is to pull the file system into the workspace. I did a
    very simple stab at that for my product, automatically creating a
    project that holds (if possible) the folders containing open "external"
    files, (Ed, I know you'll remember this approach), adding Browse
    buttons
    to the wizards and Save dialog, etc. It makes search and markers work
    and allows virtually every file to be opened as an IFile, but it's a
    bit
    of a hack.

    Bob

    Ed Burnette wrote:
     > I've long thought that IResource should be able to represent
    things other than "files and directories in the local file system
    that happen to be in projects in the workspace". Even local file
    system files outside the workspace can't currently participate as
    first class citizens in the IDE (with markers and search and the
    other benefits that come with being an IResource).
> > For related bugzilla entries see: 
     > https://bugs.eclipse.org/bugs/show_bug.cgi?id=37935#c7
     > https://bugs.eclipse.org/bugs/show_bug.cgi?id=54900
     > https://bugs.eclipse.org/bugs/show_bug.cgi?id=37723
     > https://bugs.eclipse.org/bugs/show_bug.cgi?id=58179
     > https://bugs.eclipse.org/bugs/show_bug.cgi?id=29389
     > _______________________________________________
     > platform-core-dev mailing list
     > platform-core-dev@xxxxxxxxxxx
     > https://dev.eclipse.org/mailman/listinfo/platform-core-dev

Back to the top