This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
There are many problems/bugs in externaleditor just because it coexists with the NetBeans Source Editor window [NSEW] . To solve the problems, more control about NSEW is needed. One way to do it is supplying Netbeans with the Top Component class for NSEW and JEditorPanel's to hold the documents. Of course this requires an API change. Here is my proposed API change: ================================= There can be an interface NbEditorKit: public interface NbEditorKit { /** Gets the class of the TopComponent to be used * This class should be an subclass/instanceof org.openide.windows.TopComponent */ public Class getTopComponentClass(); /** Gets the class of the editor pane * This class should be an subclass/instanceof JEditorPane */ public Class getEditorPaneClass(); } When NetBeans opens documents, it checks the EditorKit registered for that MIME type. If an EditorKit is an instanceof NbEditorKit (by implementing those two methods),then: 1) NetBeans can use the TopComponent provided in that EditorKit 2)it can instantiate the given EditorPane and open the documents in them (Note here that a user may subclass both the JEditorPane and TopComponent for his needs.) If the EditorKit doesn't implement NbEditorKit, then Netbeans can use what it is using now as the default TopComponent and EditorKit, i.e CloneableEditor and JEditorPane respectively.
Yarda, your opinions?
Jesse has bigger experience in this area. I would like to know his comments.
This might work, I hadn't thought of approaching it from this angle. Please take a look at the jglick-emacs-smart-windowing-branch in openide/src/org/openide/text/ and see if that could be better implemented in this style - i.e. if the module could actually supply a reasonable TopComponent and JEditorPane. Remember that the module needs to be able to suppress making the TopComponent visible; I'm not sure if that is possible. New Commands API work will probably also be relevant here, because you will want to be able to set the activated nodes (= lookup) when your editor is focussed to be some arbitrary list. I.e. some way to replace the call to TopComponent.Registry.get* from action classes with something that will permit an arbitrary Lookup to be returned, where the looked-up objects will normally be Node's. It's not clear to me that any TopComponent is actually required at all for externaleditor. JEditorPane is definitely needed because the EditorCookie interface requires it, and people do sometimes ask for the caret etc. What externaleditor probably needs to do is to make an invisible JEditorPane and then manage requests such as opening, closing, focussing, etc. as delegated from CloneableEditorSupport, where the default is to delegate these all to a CloneableEditor. I don't like returning classes from the interface. If it is factory, it should act like one: TopComponent createTopComponent() etc. This is a very subtle topic and I don't think it's wise to start adding APIs without a working proof-of-concept. I'd recommend a complete proposal be written explaining the problems, the suggested API changes, and how the API changes solve the problems; and a branch made in which the API changes are implemented and in which the externaleditor takes advantage of them. Only then can we see for sure that the proposed technique will work.
Fixing component and type.
Melih, what do you think about Jesse's comment?
It seems like we agree on the issues: J> JEditorPane is definitely needed: Agreed. The externaleditor should provide the IDE with the editor pane (preferably subclassed from JEditorPane) where it can manage the UI requests (focus etc). J > It's not clear to me that any TopComponent is actually required at all for externaleditor: The more I think about it, the more I agree with Jesse. We may not need the TopComponent. But we may subclass the CloneableEditorSupport to have more control. J > I don't like returning classes from the interface: I don't have a strong preference here. We can either return the class or create an instance of JEditorPane and CloneableEditorSupport and return it. That's an implementation detail and I can live with both ways. J > ... working proof-of-concept To branch and implement the API changes required on both the IDE side and externaleditor side will take time. I'll look into it when I have more time. Additionally, please see also #16137. That's also related, because it's a problem which is a result of externaleditor coexisting with NSEW. I did mention two possible solutions there and for one of them I did file the bug # 20442. Maybe we need to discuss that issue also on this thread.
Created attachment 4885 [details] Patch of CloneableEditor to allow EditorKit to provide its own JEditorPane
I've attached simple patch that demonstrates the possible communication between CloneableEditorSupport and EditorKit. It allows to replace the JEditorPane. I am sure that during the work on external editor you will find out that the communication should be more rich. In such case I suggest to create an abstract class that would abstract all the necessary communication between CloneableEditorSupport (it is not possible to subclass it because other modules do) and the editor and retrieve this class from the EditorKit instead of the JEditorPane. I wonder how the class will look like...
Created attachment 5125 [details] extends Yarda's original patch
Yarda, I did try your patch and it's working fine. I made some additions to it to display a message to the user when external editor is used instead of Built-in one(see attachment CloneableEditor.diff2). Please integrate the changes in the trunk and in orion_fcs and close the bug. Thanx.
Few problems: 1. we cannot put the TextArea part of the code into our codebase. But I believe that you can achieve the same effect by implementing the NbDocument.CustomEditor interface, just create the TextArea there. 2. I studied the code again and I have to admit that right now I do not understand why you need own subclass of JEditorPane? Because you override the requestFocus () method? Or for some other reason? If there is no other reason than it will be better not to introduce the javax.swing.text.JEditorPane property but just change the code to call requestFocus on component returned from NbDocument.CustomEditor
OK, here are the answers: 1. Please supply me with a patch so that I can try it by implementing the NbDocument.CustomEditor interface. 2. This won't work. I want the component which I will return to you being able to have the focus(the textArea in 1 will be visible there) but not the JEditorPane.(if you wanna see my version of JEditorPane just look in ExtEdEditorPane.java in externaleditor module) So, lets keep javax.swing.text.JEditorPane property as we agreed before. And I will let you know if 1) works when you give me a new patch. thanx.
Created attachment 5143 [details] Diff of patch to try out.
Created attachment 5144 [details] Patch to try out (put in lib/patches) read next comment.
Melih, Yarda is not here today. please try out the patch, that's different from previoius one. You have to do something also: Let your document implement NbDocument.CustomEditor the way it returns your already initialized TextArea. Then when focus added to the editor it will be passed to the text area. If it works for you, have a look if it still works for normal editors. Thanks, Peter
Execuse me for not looking to ExtEdEditorPane sooner. The only purpose of the class I have realized is to be invisible. So please try: ExtEdDocument implements NbDocument.CustomEditor { public Component createEditor (JEditorPane pane) { return new JTextArea (); // as in your patch } } that way you will be able to fully control the content of the editor tab without displaying the textual content and without providing your editorpane because it will never become visible.
*** Issue 21929 has been marked as a duplicate of this issue. ***
Yarda and Peter, I did try the patch and it's working fine. My createEditor (JEditorPane pane) returns a Component which embodies: 1) the pane, sized to w=0 h=0 2) info pane, which displays a message to the user when external editor is used instead of Built-in one (as before) So, please go ahead and check-in your patch into the trunk and orion_fcs. Thanx.
Fixed in [main-trunk] Fix: openide/../text/CloneableEditor.java [1.36] editor/../libsrc/org/netbeans/editor/EditorUI.java [1.34] // needed // change to keep delegating focus the old way for editor.
Created attachment 5262 [details] "official" diff of patch to [orion_fcs] branch.
Created attachment 5263 [details] Patch for [orion_fcs] part 1, put in lib/patches dir.
Created attachment 0
Please review, test and approve for [orion_fcs] integration.
Refined patch in [main-trunk] Rollbacked the editor part change. There is focus request delegated to custom component only in case, it doesn't contain the original pane. Fix: openide/../text/CloneableEditor.java [1.37] editor/libsrc/org/netbeans/editor/EditorUI.java [1.35]
Created attachment 5264 [details] Diff of refined patch.
Created attachment 5265 [details] Refined patch.
Melih please try out the refined patch, it is should be the final one, it is much more suitable for us, it doesn't require to change our one editor custom component. Also when you implement the NbDocument.CustomEditor don't put the pane into your component sized to [0,0]. If you don't need it don't use it, just return your component. Thanks.
Peter, I tried the refined diff in CloneableEditor.java and it's working fine. Because of some focusing issues, I have to put the pane as 0,0 in the Component I am returning to you, but it seems not causing any problems. (Is there any specific reason why you don't want the pane in the Component?)
*** Issue 17398 has been marked as a duplicate of this issue. ***
Melih, The reason is only if you put the pane into your custom component requestFocus will be called on the pane, if the pane is not in the custom component hierarchy, requestFocus is called on the custom component directlyi. For me it just seems to be needless to put the pane there, but it's completelly up to you. Honza, Petr, please let test and approve the last patch for [orion_fcs] integration. Thanks.
Integrated into [orion_fcs] branch.
verified for #020410_02