Download NetBeans!

20070321 Wednesday March 21, 2007

We've Got a Groovy Kind of Editor

Some fun. I seem to have made a Groovy kind of editor... It has a 'Source' view and a 'Console' view. All of it is built on top of the Manifest Multiview sample, which illustrates one of the chapters in the forthcoming NetBeans Platform book. It does not use the unstable XML Multiview API, but just the standard one that's been in the NetBeans Platform forever. Below is my new Groovy editor in NetBeans IDE, with code that comes from Getting to Know Groovy, which I have found to be a very useful article. (This editor is just a draft, by the way. Not all the tokens are colored, and not all tokens are correctly colored, as explained later in this blog entry.)

Above, the "Source" and "Console" are buttons for toggling between the two views. The "File", "Edit, "Actions", and "Help" are the menus from the Groovy Console. (More about that, especially for NetBeans purists who don't agree with having these menu items in the visual view, further on in this blog entry.)

The two sides are synchronized, so that changes made on one side are set to the other side, in the componentActivated() method on both sides. (Some kind of 'Save' action needs to be added, so that the user can choose whether to synchronize the two sides.) However, the synchronization is handy, because it means the user can use the Source view for typing Groovy code, and then use the Console view for testing it!

Quickly looking under the hood, for those who might be interested, the synchronization approach is really simple. This is code in the source view's definition, which checks to see if the Groovy Console (i.e., the visual view embeds the Groovy Console) was started ("isConsoleRunning" should probably be called "wasConsoleStarted", because it is exited after it is started, as explained in recent blog entries), and then retrieves the content of the input area, pasting it into the NetBeans editor (thanks to a recent discussion on dev@openide.netbeans.org, I now know how to replace Registry.getMostActiveComponent(), as shown below):

public void componentActivated() {

    super.componentActivated();

    String inputFromVisual = null;

    //First check that the console is running,
    //which implies the the Console view has been opened
    //at least once:
    if (GroovyVisualView.isconsoleRunninng()) {

        //Get the text from the Groovy Console's input area:
        inputFromVisual = GroovyVisualView.getConsole().getInputArea().getText();

        //Next, check that there is actually something in the input area:
        if (!(inputFromVisual.equals(""))) {

            //Get the current NetBeans document:
            JEditorPane [] jeps = Utilities.actionsGlobalContext().lookup(EditorCookie.class).getOpenedPanes();
            for (int i = 0; i < jeps.length; i++) {
                JEditorPane jEditorPane = jeps[0];
                //Set the text of the current document to the Groovy Console's input area:
                jEditorPane.setText(inputFromVisual);
            }

        }

    }

}

In addition, notice that the Source view has some syntax coloring. (It would be nice if the Console view's input area had the same syntax coloring, but that would mean rewriting the Groovy Console, or implementing my own, because the current input area is a JTextArea, which means I can't set a MIME type. Pity it isn't a JEditorPane or JTextPane, like the output area.) That's based on the Groovy.nbs file in the NetBeans sources, to which I added new tokens for Swing components in Groovy. Can anyone give me a COMPLETE list of Swing components in Groovy (such as "menuItem" and "panel" and so on)? Currently, notice that I haven't identified all the tokens yet (which is why I'm appealing for a complete list here), as a result of which Swing components such as "menuBar" are not colored in the illustration above. So, I need all the Groovy tokens (as well as as much of the grammar as possible), please... otherwise this Groovy editor will not be so groovy. The full impact of Schliemann can only be felt once all the tokens are filled out completely, then code completion, code folding and all the other features can be added without much problem.

All of this probably looks a lot more impressive than it really is to implement it. Each part of it is very trivial. NetBeans purists might argue that the Console's menu bar should not be displayed in the visual view. Instead, the menu items should be migrated to the NetBeans IDE's menu items. Well, I disagree, and here's why... in NetBeans 6, with the undocking functionality, one will be able to undock each of the Groovy documents (and any other documents) from the IDE, so that, for example, this effect results:

Here, doesn't it make sense that the menu bar is in the visual view? This way, I could be working on multiple Groovy documents simultaneously, potentially spread across multiple monitors. The more control I have localized to the document, the more sense it makes to undock my document.

Anyway, there's a lot more to be said about all of the above, but clearly... we've got a Groovy kind of editor. By the way, the same editor infrastructure (i.e., this multiview editor) could be used for any scripting language, if it has some kind of console or other visual view. A simple check could be done on the MIME type, and then, depending on the MIME type, the applicable visual view could be loaded on the visual side of the editor.

This is the only Groovy-specific part in the editor, on the visual side, for loading the console into the visual area and the menu bar into the toolbar:

public MultiViewElement createElement() {

    Binding bind = new Binding();
    console = new Console(this.getClass().getClassLoader(),bind);
    console.run();
    consoleRunninng = true;

    container = console.getFrame().getContentPane();
    menubar = console.getFrame().getJMenuBar();

    console.getFrame().setVisible(false);
    this.revalidate();
    console.exit();

    return this;

}

public JComponent getVisualRepresentation() {
    return (JComponent) container;
}

public JComponent getToolbarRepresentation() {
    return menubar;
}

So, in the methods above, we could check the MIME type and load other stuff into the visual view, depending on the language that we're dealing with. Therefore, this isn't just a Groovy editor, but potentially useful for other languages with a console (or something similar) as well.

Mar 21 2007, 05:13:52 AM PDT Permalink