[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-core-dev] Re: IResource outside the workspace
|
John Arthorne wrote:
There is a "story" for how this can work, although it's admittedly not
practical in many cases:
Yup.
...I know this is a confusing and little known feature. In the UI
we only have "new" wizards and "import" wizards. If you want to create a
"new" Eclipse project but with existing content on disk, it's not
intuitive that you would go to the "new" wizard (In this case "new"
means new to this workspace). It's further confused by the fact that
some "import" wizards will also create new projects (import existing
project, import from CVS). What the user often wants is some hybrid
new/import wizard where they can specify the project type and the
project content all in one go. The UI team has often struggled with how
to improve this, and I'm sure suggestions are welcome.
I filed a bug report on this right after you pointed out the feature to
me. Contains a suggestion. ;-}
https://bugs.eclipse.org/bugs/show_bug.cgi?id=105603
...Markers are not inherently an IDE concept, but their API pulls
in IDE-specific concepts (just for fun:
IMarker.getResource().getProject().getDescription().getBuildSpec()...
suddenly you're in distinctly IDE space).
Probably seemed ok at the time. Now it's a big roadblock.
While the editor framework
handles this split between annotations (RCP) and markers (IDE)
You can't as a practical matter show annotations in RCP because
AbstractDecoratedTextEditor, that handles getting the annotations drawn,
is heavily IDE-dependent (not just markers).
, this
doesn't carry over into other views that currently only know only about
markers (tasks, problems, bookmarks, ...). The problem is, you need
somewhere to store these annotations. When a random file from the file
system is opened in an editor, and annotations are added, it's not clear
how those annotations can be persisted in a way that they will stick
with the file if it's opened elsewhere.
Perhaps it's not clear because the solution you now have depends on a
persistent IResource workspace. The same could be done for your
trimmed-down "RCP equivalent of IFile". You may be thinking, omygod we
can't mirror the entire file system in metadata(!), but you don't need
to save metadata if you don't have any to save. By retaining metadata
only about files of interest, you'd have the same issues of
synchronization with the file system you do now.
I believe there is also editor
work planned for 3.2 to push more editor functionality down into the
"RCP-enabled" editor plugins.
A good thing for sure. If they can push AbstractDecoratedTextEditor into
RCP, they'll have pretty much done the job.
(You need markers that are independent of the IDE; you need a way to
persist java.io.File-related "properties"; you need to weed out the
dozens of IDE assumptions, especially in actions. I did an experimental
implementation of this in a couple of weeks, using dependency injection
into AbstractDecoratedTextEditor to replace a number of static
references to IDE functionality. It worked to the extent that editors
ran and showed markers and error annotations, but action handling was a
problem and I decided the whole thing was unmaintainable. What really
needs to be done is completely replace the current markers/annotations
(annotations in particular are an overgrown thicket of extensions and
obsoleted API) and support the current API as a compatibility layer. A
lot of work!)
...I'm
instead leaning towards the idea of a trimmed down RCP equivalent of
IFile (something closer to java.io.File but something that clients could
implement). You would then be able to create IDE IFiles on top of that
layer, or just use the "RCP file" to avoid dragging in other unwanted
dependencies.
Sounds like an excellent approach!
Bob
