Hosting text editors in views - is it possible

As some of you might have noticed from past postings, I normally prefer to use only views in RCP application and no editors at all...

One of my new customers already have a text editor (based on TextEditor) as an Eclipse IDE extension they want to bring over to a new RCP application. One of the questions, we now have to assert is whether to use editors in the RCP application in question or try to redo the editor as a view.

But, before we start on this work, I just wanted to hear if anybody out these has tried to do this before and have a qualified meaning about the issues involved. Is it at all possible? Or is it just a lot of work?

We understand that the real work is in how to use SourceViewer and friends, and that seems to be doable in a view, but...

If it turns out to be very difficult to implement editors in view, we might just dedicate a speciel perspective for this, but the best solution probably would be to use views only.


Vineet said...

I did this over a year ago and it was not too hard (but I did have the ability to modify the code of the editor...)


Anonymous said...

@Vineet, I do expect to modify the code quite a bit... But I want to tap into the big infra structure of SourceViewer and friends to get something that looks as much like the "real" thing as possible.

How did you handle the DocumentProvider API?

Heath said...

I did this about 2 months ago on the 3.3.2 release of eclipse. The major pain points are replicating usage of extensions generally associated with TextEditors. There is really no reason that those extensions cannot also be associated with a SourceViewer, but the TextEditor gives it to you for free.

I was mainly trying this out as a way to annotate and decorate text I was generating for user output rather than providing editing facilities, so my use case might be a bit simplified.

Ultimately, I was unable to use the SourceViewer because native line wrapping doesn't work with it right now. Below is a link to the bug requesting line wrapping in TextViewers.


Thomas said...

Hello Tonny,

it is my job to migrate the functionality of an existing standard Text Editor having jface based content assist, a presentation reconciler, reconciler and so on from a UI.Editor context to a UI.View context.

I had no problem creating a SourceViewer in a UI.View context and attaching the original SourceViewer-Configuration of the Text Editor from the original UI.Editor context. Note that I didn't make any changes to Content Assist, Presentation Reconciler, Reconciler, etc.

This results in my SourceViewer (UI.View context) working almost like the original Text Editor (UI.Editor context),except for a big problem I have with Content Assist. The proposals are not proposed in the same way as they were in the Text Editor from within the UI.Editor context.
The Content Assist in the UI.Editor context recognizes input history and then creates the Proposal based on this history and any other tokens a parser may deliver based in turn on its internal model state.
The Content Assist in my UI.View context, however, doesn't show the correct proposals, even though I didn't change any code in the Content Assist - as noted previously. It seems that the reconciler (i.e., parser) has a problem finding the right position of the caret - and therefore its model state. I get a parser error "Invalid replace region".

Now, I didn't integrate a Document Provider (UI.Editor context) in my Source Viewer (UI.View context). Could this be the reason for the wrong behaviour of my Content Assist in the UI.View context?
Do you have any experience with migrating standard Text Editors embedded in a UI.Editor context to a UI.View context? In particular, have you encountered the Content Assist problems I described above in a UI.View context?

Thanks for any help.

Thomas Vanek

Anonymous said...

@Thomas, I do not have any experience with this. We opted not to use a text editor in the end... So I yet have the pleasure of trying this out... /Tonny