Community
Participate
Working Groups
In an RCP application, to use the default text editor (TextEditor class, id org.eclipse.ui.DefaultTextEditor) I have to pull in the org.eclipse.ui.editors plug-in. However this has a dependency on org.eclipse.ui.ide and org.eclipse.core.resources - two plug-ins not intended for RCP applications. The editors plug-in also uses org.eclipse.core.filebuffers which would be ok except that one also depends in one place on org.eclipse.core.resources.
The default text editor uses a workspace file as its input. org.eclipse.ui.editors really is ide specific. It does not have .ide in its name for backwards compatibility with 2.1. It provides the default text editor for the IDE, not the default editor for all RCP apps. The Text component can't really provide a generic text editor that is applicable for all RCP apps since it does not know the underlying data model of the app. If you want to use the text editing framework in your RCP app, you need to include the org.eclipse.workbench.texteditor plugin (and all its prereqs) and write your own subclass of AbstractTextEditor (or StatusTextEditor) that takes an appropriate input and has an appropriate document provider. Moving to Text for further comment on what is required for RCP apps to implement their own text editor.
In this case, the underlying data model is just that I want to edit a text file on disk. I've been trying to use AbstractTextEditor and it looks possible but far from desirable. Look at all the encoding support and save-as support you'd have to reimplement for example. Reading over the code in org.eclipse.ui.editors, 99% of it is NOT resource specific. Even in the references to IMarker, only one place actually did a getResource() call. I think it would be straightforward to split out the few resource specific parts into a .ide package. First thing you could do is copy IMarker to org.eclipse.core.runtime.IAbstractMarker except for the getResource() method, and make IMarker extend it and add getResource(). Then all the editor code would switch to IAbstractMarker. (I'd suggest using IMarker for the basic interface and IResourceMarker for the sub-interface with getResource() if it weren't for all the current users). Splitting IMarker like lets you keep all your annotation model stuff and could possibly benefit the searching code too (though I haven't seen the new searching code). Next, resource specific parts like ResourceMarkerAnnotationModel and FileDocumentProvider would move to a new package, for example org.eclipse.ui.ide.editors. The new filebuffers package used by the editors is almost completely resource independent from the source code I've read so far, except for the FileBuffer facade, ResourceFileBuffer and a couple of constants. So the next step would be to split out the IDE (resource) parts to their own package leaving the non- IDE parts where they are. The goal would be to get ExtendedTextEditor and TextEditor and everything under it to NOT depend on the IDE (resource) code. Then the RCP could provide a full featured, easy to use text editor for files if that is what the application calls for.
The org.eclipse.ui.editors plugin's dependencies contribute preference pages and the resource perspective. Removing the IDE dependencies from org.eclipse.ui.editors would allow RCP apps to use the editor framework without the unwanted UI contributions.
As described in comment #1, org.eclipse.ui.editors's dependency on org.eclipse.ui.ide cannot be removed -- this is the IDE-specific portion of the Text component. RCP apps need to build on the org.eclipse.ui.workbench.texteditor plug-in, and not include org.eclipse.ui.editors. Several people interested in RCP have asked about how to use text editors. Can someone on the Text team please describe the steps involved? An example would really help. It would also help for people interested in this to describe what kinds of content they want to show, and where the content is coming from.
It would also be good to describe any known limitations of using Text in RCP apps, e.g. is it possible to use shared buffers, and will that require a dependency on org.eclipse.core.resources.
We will provide an example of how to use the org.eclipse.ui.workbench.texteditor plug-in in an RCP application. Limitations are given by the plug-in dependencies. I.e. file buffers cannot be used. We will not provide a ready-to-use RCP editor solution for 3.0.
Such an example will be very helpful. Including org.eclipse.core.resources in an RCP app is not ideal, but is not tragic. It costs ~700K in disk footprint, and doesn't contribute anything to the UI.
Removing target milestone, no further action for 3.0.
Note that a very simple example of creating a text editor based on the RCP drop (plus the additional o.e.text, o.e.jface.text and o.e.ui.workbench.texteditor) has been made available at http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-ui-home/rcp/index.html It does not support encoding nor shared filebuffers nor currently an annotation model.
I'd like to add weight to the original request. I'm finding myself in a situation where I'm having to copy code from the org.eclipse.ui.editors plugin into my implementation of AbstractTextEditor simply because I don't want the IDE dependencies. It feels like this plugins should be generalised to be in the first instance independent of the IDE, and a new IDE plugin added which contributes the IDE specific components. I'm in agreement with Ed that this doesn't seem like a massive job.
>I'm in agreement with Ed that this doesn't seem like a massive job. If so, and if this item is really important to you please provide a patch and attach it here for review.
*** Bug 121554 has been marked as a duplicate of this bug. ***
As of now (I20070220-0800), the file buffers plug-in's dependency on 'org.eclipse.core.resources' is optional as long as only non-resource dependent functionality is used. The file buffer manager can be reached via ITextFileBufferManager.DEFAULT and there is also a GenericFileBufferOperationRunner. Also note that since 3.3 M5 the application specific part has been removed from the IDE plug-in into a separate plug-in (see bug 167893 for details). This means that for clients which do not care too much about their RCP's size the easiest way to build an editor is to simply start off org.eclipse.ui.editors. I'm marking this one as fixed since either ui.editors can now be used or file buffers can be used along with org.eclipse.ui.workbench.texteditor.
