Picking up from yesterday , let's look at one of the Filthy Rich Client samples. In chapter 9, we can read all about glass panes. This Swing component gives us access to the complete surface of the user interface, in one unbroken piece. It is like a thin pristine layer of ice over a pond full of turmoil and complexity. And it is invisible by default.

The first sample discussed in chapter 9, to illustrate glass panes and what you can do with them, looks as follows when up and running:

When confronted with the question: "How useful is all this filthy rich client stuff anyway?" The above is a good example of the 'filthy rich client' experience being very functional. Here, we are giving the user visual feedback about the state of the application and the way in which we expect the user to react—something is downloading, ergo the user should go and get some coffee, or something, but whatever happens, the user should not think that they can continue working while the download process is occurring. That's the visual feedback one gets from the above, which is clear even to the most novice of novices.

In this article, we will look at the sources of the sample, which can be downloaded (for free!) from the Filthy Rich Client site. In the screenshot below, you see the project that contains the sources. The upper one, with the orange Java cup icon, is exactly what you will have when you download the sample from the aforementioned site. Below that, with a purple icon, we see something different. That is the source structure of... a plugin! Have a look at it below:

To create that plugin source structure, together with the additional Java source files above, I did the following:

1. I used the New Module Project wizard (available in the New Project wizard) to create the plugin source structure. The source structure, as one can see above, has an XML file called layer.xml . Most NetBeans plugins have that file. It is mainly used to declare the user interface elements that the plugin will contribute.

2. In this case, the layer.xml file provides an entry declaring that the DownloadAction class should be invoked from a menu item. In fact, it specifies that that menu item will be invoked from the Tools menu. I didn't need to type that declaration in the layer.xml file. Neither did I need to create the DownloadAction class. Both of these were generated by the New Action wizard, which can be accessed from the New File wizard, for any NetBeans Module project.

3. And what will happen when the DownloadAction class is invoked? I copied the code that I found under the JButton in the original sample (i.e., the one you see above) and pasted it into the action's performAction event. With one significant difference. Here is the original code, under the "Start Download" button:

   getGlassPane().setVisible(true);
   startDownloadThread();
   

   And here's the declaration of the glass pane:

   private ProgressGlassPane glassPane;
   

   Finally, the constructor sets the glass pane:

   public ApplicationFrame() {
       initComponents();
       setGlassPane(glassPane = new ProgressGlassPane());
   }
   

   Now, in our plugin, we would declare the glass pane, exactly as before. And then... we would need to do a little bit of work in the menu item's performAction event:

   final JFrame mainWin = (JFrame) WindowManager.getDefault().getMainWindow();
   mainWin.setGlassPane(glassPane = new ProgressGlassPane());
   glassPane.setVisible(true);
   startDownloadThread();
   

   As in the original, we enter a thread that handles the download process, as described in the book from page 227 to page 230. However, in the lines before that , where the original application gets the glass pane from the JFrame , in our plugin we need to get it from NetBeans IDE itself. Or, more correctly, from the NetBeans Platform, which is the thin kernel upon which NetBeans IDE ( and many other applications ) is built. In other words, not from JFrame , but from org.openide.windows.WindowManager . Once we have that , which is provided by the NetBeans Window System API , we can get the glass pane, because we can cast the WindowManager to a JFrame .

4. At this point, having transferred the thread code, and the glass pane initialization, into my DownloadAction , I no longer have any need for the original JFrame from the sample. However, the ProgressGlassPane , i.e., the JComponent that is set as the glass pane, is 100% applicable, exactly as it is. This is a typical scenario with plugins in the context of NetBeans IDE—if you have Swing code in your original application, then you can, by and large, simply copy that Swing code straight into a plugin's source structure. Typically, you'd need to tweak a thing or two, to smoothen the transition between your Swing code and the rest of the plugin, but you'll be surprised how trivial this part of the task can be. Above, in the previous step, I moved the code around a little, and then I was done.

5. At this stage, you can right-click the project node and choose "Install/Reload in Target Platform". When you do this, a new instance of NetBeans IDE starts up. Your plugin is then installed in it. (Alternatively, you can install the plugin directly into the same IDE in which you created it.) Once it is installed, go to the menu that you specified in step 2, choose the menu item, and 'hey presto', you now see the following:

   

Side Note: Clearly, being able to provide visual feedback to the user is a good thing. However, a question worth asking is— is this the right way to do it, in this case? NetBeans IDE already has a progress bar. Look at it above, in the bottom right hand corner. This brings up related questions that will be discussed next time—when plugging into a framework, one needs to know what is already provided and also how what one has can best integrate with that . Plus, do you really want the screen to look as it does above? Don't you want the user to be able to continue working while something is being downloaded? Shouldn't that be an asynchronous process? I would tend to want to say "Yes", to that...

OK, let's step back a moment. What have we done, and why? We took a sample from the Filthy Rich Client site, created a plugin's source structure (via a wizard), and then transferred code from the sample into the source structure. Then we installed it. But why ? Answer: This is an example of how you can take existing functionality in existing Java applications and make that functionality available to applications written on the NetBeans Platform. You now have a plugin that can, well, be... um... plugged... in. All/most NetBeans Platform based application have a 'Plugin Manager' under the Tools menu (which the NetBeans Platform provides, out of the box, no programming needed at all), which is a complete, functioning, wizard for searching for and installing plugins. And that's what your users would use to install the plugin you've created above. Either send it to them or create what is known as an 'update center', just an XML file that describes the plugins and their location on a server, which your users then register in the Plugin Manager. Then they can download your plugin, an experience comparable to the Synaptic Package Manager in Ubuntu Linux.

From this exercise it is quite clear that transforming a standard Swing application into a plugin for the NetBeans Platform is not really brain surgeory. And, because it is a plugin for the NetBeans Platform, you can now install it in any application that is built on the NetBeans Platform. In the next part of this series, which will also be the final part, we will look at how to create such an application and also what you stand to gain from doing so. Again, we will see that none of it is really rocket science at all...

Update: Jump to part 1 or part 3 .