NetBeans Platform: Carefull with Matisse and FocusTraversalPolicy (aka Focus subsystem)

Matisse is a really nice GUI editor. But it doesn't seem to be quite up-to-date with the Java Focus Subsystem.

JComponent.setNextFocusableComponent() is deprecated since 1.4 ! And yet, this is all Matisse has to offer.

The right way to specify focus cycles since 1.4 is via FocusTraversalPolicy. You just set Container.setFocusCycleRoot(true) and then install your FocusTraversalPolicy subclass.

The problem is that setNextFocusableComponent has priority over the focus policy:

Overrides the default FocusTraversalPolicy for this JComponent's focus traversal cycle by unconditionally setting the specified Component as the next Component in the cycle, and this JComponent as the specified Component's previous Component in the cycle. (quote from Javadoc, emphasys mine).

So, if you try to define in Matisse some focus cycle the old fashion way (the only way possible right now) but then you want to use a FocusTraversalPolicy you have to go back and remove all the nextComponents otherwise it will break everything !

My advice: don't use nextFocusable on Matisse ! Do it by hand with FocusTraversalPolicy and wait for the 6.0 release when this should be fixed.

NetBeans Platform: Watch out for the Platform security !

I always had the impression that the Platform is quite lax security-wise. Since you have in the Lookup the system ClassLoader it's not like they can restrict your module that much.

Well, I was a little mistaken. Apparently they do add some security checks.

And a particularly strange one is a security check on System.exit().

Actually, it makes sense to restrict calls to System.exit() but the way I've discovered it is surprising: I just moved a JFrame (made with Matisse) from the Java app to the platform. And by default, JFrames, have EXIT_ON_CLOSE set.

Well, on the Platform, the JFrame won't even show up ! Why ? Because of the EXIT_ON_CLOSE property. It eventually boils down to something like:

    SecurityManager security = System.getSecurityManager();
         if (security != null) {
             security.checkExit(0);
         }

which fails inside the platform with an org.netbeans.ExitSecurityException .

So the problem is that initComponents() throws this unchecked exception so the entire new Frame().setVisible(true) call fails. Even more: this doesn't show up in the logs!

Btw, System.exit() works just fine during ModuleInstall. It's LifecycleManager that breaks down at that (early) point.

NetBeans Platform: Node.Property custom editor

The property window is a nice quick way to let the user view and edit some values. It's not recommended as a valid approach (one should make its own windows) but it is quick. Just provide some activated nodes, open the Properties windows and all the declared PropertySets will be visible.

The nice part is that we already have a lot of predefined PropertyEditors for boolean/integer/string/font/color/date values.

But if one of the editors doesn't please us, just use Node.Property.getPropertyEditor() .

For example if we need a different date format, it would boil down to a new class:

  class DatePropertyEditor extends PropertyEditorSupport{
   private SimpleDateFormat sdf=new SimpleDateFormat("yyyy/mm/dd");

   public String getAsText(){
    if(getValue()==null){
     return "";
    }else{
     return sdf.format((Date)getValue());
    }
   }
  }

We just return a new instance of this class in getPropertyEditor() and that's it.

This gets a little more complicated if you actually need to edit the value as you have to provide a custom editor component but for simple read-only properties, this is all there is !

NetBeans Platform: 1st NetBeans Platform workshop in Timisoara. Make that in Romania

Today was the first NetBeans Platform workshop and presentation in Timisoara, held by your's truly. I'm also about certain it's the first in Romania too.

My ex-employer had this Java-workshop about various subjects (Struts, MVC, Hibernate, Design Patterns, Swing and NetBeans (Platform) ).

The presentation was quite nice. There were few people but with many questions (yeah, I'm looking at you Dan ! ).

I had a small OpenOffice presentation as the starting point and in the end I worked only in the NetBeans IDE, showing off:

• The module system (dependencies, modules, module suite, module enable / disable).
  
• Actions API
• Progress API and RequestProcessor.
• TopComponents with activated nodes.
  
• Node PropertySets (quick demo using the Properties window -- that's why I used activated nodes and not the TopComponent Lookup).
• Service declaration with META-INF/services and lookup using Lookup.getDefault().
• Lookup listener on Lookup.Result. Nice to detect new service providers being activated (with a new module).
• Options Dialog and SPI
  

I only remembered I had a camera at the end of all the discussions. I was too bussy answering questions ;)


I'll try and post another picture with the NetBeans powerpoint in the background later on today or tomorrow. Of you could just download the presentation together with the small application written on the spot.

UPDATE(11.dec.2006): New photos on Flickr.

NetBeans Platform: TopComponentGroup strangeness

Ok, I never used window groups as I wasn't that used to have that many interdependent windows.

It seems easier to add a "Palette" inside your JPanel and it surely is easier to handle than to make a separate window tha listens on the Lookup/activated nodes and reacts.

TopComponentGroup seems like the next logical step: if you already started using a whole bunch of windows that are interconnected somehow put them in the same group.

The teoretical advantage would be that
1. You get to easily open and close the whole group. You don't even have to know *who* is in the group. (Note the nice decoupling you get there).

2. The Group implementation remembers the closed/open state of contained TopComponents and restores them in the same way. This makes it consistent with the user.

Well, it's number 2 that annoys the hell out of me. For example: what if I *don't* want to remember the state ? What if I have 3 TopComponents that work together but they should *always* be in an open() state together ?

What do you do then ? Of course: do it manually. You lose the decoupling and have to keep hard references to your "buddy"-windows and .open() or .close() them by hand when needed.

Which means that by this point TopComponentGroup is useless and you might as well remove all the code/xmls. Grr.