8 comments

Hello softwarevisualization,

Is it possible to extend the Editor implementation , either through
wrapping and delegation or through extension?


What exactly do you mean? If you want to extend IntelliJ IDEA's text editor,
there are some ways you could do that, depending on your requirements.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0

Maybe saying what I am trying to do would be good. The History view is really a view of the current file next to a view of a previous version, plus specialized highlighting , actions etc. This is useful because it shows you your document as if in the editor (even though it's not editable) and ALSO more stuff which bears information....so it's taking your .java file as you know it and marking it up in situ, that is, right there in the "editor", as opposed to another tool window or in the gutter or where have you.

I would like to do something along these lines. So I imagine my choices are override and extend or implement from scratch one or more of the following classes / interfaces:
the
Document
Editor
FileEditor
EditorFactory
etc

or
or even better wrap./ extend / inject some of the above to use my EnhancedEditor.

I am not looking to change or alter the way the editor works. I am only looking to append stuff to the presentation of the class, which stuff exposes relationships, metrics, etc etc....

0

or a third choice I thought of was to utilize the GlassPane over the Editor... I can do any or all of these, but I am not sure if any of them are possible through the OpenAPI

0

Hello softwarevisualization,

or a third choice I thought of was to utilize the GlassPane over the
Editor... I can do any or all of these, but I am not sure if any of
them are possible through the OpenAPI


You can certainly use the GlassPane, although there's no special support
for it - you'll need to set it up by yourself, and track editor scrolling/sizing/splitting/switching
manually.

If you don't need to do any custom painting and can stay within the limits
of IDEA's supported decorations (gutter bar and icons, text coloring, underlines/borders
around blocks of text), your job will be much easier - you'll be able to
add these decorations into the standar IDEA editors.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0

Is it possible to create a custom editor (of any sort.. for images of HTML or what have you) and put it in the main editor pane window?

And if it is possible, could I create a special editor which, perhaps through the device of internal delegation FROM my special editor TO the "usual" editor, presented the text of the usual editor and "passed through" edits ?

For this approach it seems to me I would need three things:

one is a valid reference to the JComponent which renders the "usual" editor so I could make it a step in the rendering chain and

two a reference to the underlying Document for the purpose of edits and finally

three the ability to have appear in the main part of the screen where the usual editor appears, a JComponent of my own making.

As far as notifications to editor CONTENT goes, I assume I could get those from the same place the Editor or Document ultimately does, a change in the AST.

You make good points about scrolling, sizing, splitting, and switching, but if the JComponent in the main part of the editor is not the "usual" editor but is only exploiting the renderer of the "usual" editor, then those problems go away.



There's a discussion here:http://www.intellij.net/forums/thread.jspa?messageID=855592&#855592

revolving around someone wanting to write an editor to edit XML files. I am not sure this is not the best way to think about what I want to do.

From http://www.jetbrains.com/idea/openapi/5.0/com/intellij/openapi/fileEditor/FileEditor.html

Interface FileEditorProvider
.
.
.
javax.swing.JComponent getComponent()

Perhaps this is an interesting class? Any opinions?

0

Hello softwarevisualization,

Is it possible to create a custom editor (of any sort.. for images of
HTML or what have you) and put it in the main editor pane window?


Yes, this is certainly possible. The plugin development kit contains the
sources for the Images plugin, which does that. Many other plugins do that
too.

And if it is possible, could I create a special editor which, perhaps
through the device of internal delegation FROM my special editor TO
the "usual" editor, presented the text of the usual editor and "passed
through" edits ?


There is no built-in support for such delegation, although you can try to
implement that by yourself using some tricks.

For this approach it seems to me I would need three things:

one is a valid reference to the JComponent which renders the "usual"
editor so I could make it a step in the rendering chain and


Editor.getComponent() or Editor.getContentComponent()

two a reference to the underlying Document for the purpose of edits
and finally


Editor.getDocument()

three the ability to have appear in the main part of the screen where
the usual editor appears, a JComponent of my own making.


FileEditor.getDocument() (the FileEditor implementation will be provided
by your code)

As far as notifications to editor CONTENT goes, I assume I could get
those from the same place the Editor or Document ultimately does, a
change in the AST.


Well, you can listen to Document content changes, for example.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0

Hello Dimitry,
Thank you for your time and knowledge. I will attempt this approach and report back to this thread when I have some conclusions so others can benefit from things as they blow up in my face ;)

0

OK this is a lifecycle question I think. I am asking about the lifecycle fo Editors. Where they come from with respect to the lifecycle of applications projects and documents and how I can inject myself into that lifecycle reliably.

OK so.. I am having trouble understanding what I need to do to make sure my editor implementation is used anywhere a reference to an editor method is invoked by any code whether it's in the OpenAPI or not.

To do that, I am not sure what needs to be done or even if it's practical to try. What must be true is that at sometime when a project is loaded and after that when a Document is displayed, an Editor (an com.intellij.openapi.editor.impl.EditorImpl, though I don't see that package in the OpenAPI, that's how it reports it's own class via getClass())
gets created. That's really all I am sure of.

So I want all such editor creation activity to pass through me somehow so I can (somehow) arrange for myEditorImpl to be used. MyEditorImpl is just a pass-through wrapper that overrides a small subset of methods.

For instance, here's some code from Sascha Weinreuter's xpath plugin XPathView

FileEditorManager fem = FileEditorManager.getInstance(project);
editor = fem.getSelectedTextEditor();


the getInstance() implies a singleton so perhaps I should subclass THAT first to bring back and instance of MyEditorImpl. Here are the problems.

No knowledge of when the default FileEditorManager is created means that by the time I (somehow) replace it with my own version, internally to IntelliJ, it could have already been used by classes I know nothing about to retrieve and gain references to Editors which are stored and used throughout the lifetime of the program. That means, essentially, I show up to the party, but too late.

Moreover, even if there are no problems with that today, because there's no formally sanctioned means of replacing FileEditorManager, the above situation could come to be programmed by others at any point in the future.

No guarantee that FileEditorManager is the one and only way Editors come into existence. Even in the OpenAPI, there are any number of classes that return an Editor- including some com.intellij.debugger, com.intellij.ide.structureView and a bunch of others. Still other things I've seen are serialized class names which are used to recreate instances when the [program is relaunched etc. etc.

So there's really no way to analytically come to any hard conclusions about where and when Editors are created so that their behavior can be overridden reliably. FWIW , I am interested in TextEditors which appear to be related to Editor via composition (TextEditor.getEditor()).


That's why I am hoping that someone in IntelliJ just knows and maybe even tell me there are plans going forward to expose TextEditor in such a way as it supports having it's behavior-appearance being overridden.




Is there some point in the loading of a project or application where I can get code executed that would ensure this, like inserting a class definition in as the value to a key ala Swing UIDefaults? Or do I have to so it each time a java class is loaded through double clicking it in the tree or creating it.

I know it's a high level how-does-it-all-go-together type question, but that's the reason I can't figure it out . Perhaps the applications and projects are not structured to support this idea.

End of a somewhat rambling question.

Message was edited by:
softwarevisualization

0

Please sign in to leave a comment.