openSuSE 11, Sun VirtualBox, Windows XP, and OpenSolaris

I upgraded my laptop from openSuSE 10.3 to 11.0, and I must say that I really like it. It has many small improvements, but most importantly I have not had to decompile and compile my own ACPI DSDT, it actually hibernates correctly, and just works with the Toshiba hardware. See my 10.3 post for my issues with this laptop.

The one draw back was I went with KDE 4, and while it seems a really awesome desktop function wise, it's stability left a horrible taste in my mouth. So, I decided to give Gnome a try after all these years of being a big KDE fan. I really like Gnome 2.2, but I'm not sure if I'll keep using it or go back to KDE 3.x and wait on KDE 4 to catch up.

In my previous setup I was using VMWare Workstation 6.0 (which I paid over a couple hundred dollars). I really liked it function wise, mostly. The main draw back is it wasn't really kept up to date to run on newer kernels shipped with Linux distros such as openSuSE and probably even Fedora. At least I couldn't find the updates, and I was having to resort to hacking the source code to get it to build against my kernel. So, I gave Sun's VirtualBox a try, and I must say that I've been very impressed with the overall performance and Linux distro updates, but there are a few things it needs to do better.

VMWare Workstation will let me use multiple monitors just like X. In other words (see my screen shot) I literally have two separate screens which I may drag windows across. A single desktop with two monitors. Pretty common indeed. Well, VirtualBox doesn't support this. The best it can do is have a single window non-full screen stretched across my multiple monitors. Not so great (horrible actually). See my screen shots from the 10.3 and VMWare post to see what I mean; check out Vista.

ALSA sound support is very choppy. I don't know what the deal is, but VMWare had this issue too though my other applications such as Firefox, Banshee, etc are fine. Right now, what VMWare couldn't do, I'm using OSS for sound, and this is a little better, but it gets choppy when I try to use something like Napster and play my music from Windows.

Seems networking is easier in VMWare. This is probably due to custom network drivers which VirtualBox doesn't have, so VirtualBox can't easily, and independent of the network interfaces, setup standalone network interfaces. Now, it wasn't such a big deal to setup VirtualBox from a networking perspective, but I venture to say those newer to Linux or Unix will have a harder time getting VirtualBox working than VMWare if they need to go beyond NAT.

In my setup my virtual machines have their own IP addresses. This way they act as true independent computers when I need them for testing etc, and this makes network shares and other necessities much easier to use. Anyways, I had to setup a bridge, disable NetworkManager, and do some things by hand versus using the GUI. Having to disable NetworkManager means using wireless networks will now be harder as I have to use the keyboard versus a UI, but as I've used Linux for years it is not that much harder for me.

USB interfacing seems to be harder. I haven't gotten this setup yet, but I haven't really needed it yet, so I haven't done much digging. Regardless, it isn't working out of the box where as VMWare did. In VMWare I could just connect a USB device, connect it to the virutal machine with the UI, and I was using it without the need for any extra dependencies in the OS. Seems VirtualBox has some dependency I'm missing from my openSuSE installation.

OK, screen shot time. In this screen shot, I'm running two monitors, one with 1440x900 resolution, and the other with 1680x1050. I can full screen a virtual machine on either monitor, and after I install the virtual box extensions into the guest operating systems they can resize their resolutions to fit the resolution of which ever monitor I happen to be running or the size of the Window in which they're running. At least this is true for Windows. In this screen shot, I'm updating Windows XP to service pack 3, installing OpenSolaris 2008.05, building a NetBeans 6.5 daily build, and browsing the openSuSE online store. Enjoy.

Make adding properties to classes in NetBeans a simpler task

NetBeans has a great feature called Code Templates. This is used to create shortcuts which may be typed in the editor then expanded into a template which the editor will ask the user to fill in the blanks. There are many useful ones which come configured upon installation within the NetBeans IDE, but one I have used for a long time, yet never written about except on the NetBeans mailing lists, is one to create properties more easily.

These properties are plain properties un-bounded and not incorporating property change events, but none the less very useful, and it isn't much work to transform into your choice of other useful property creating templates. Without further delay, my code template is:

private ${TYPE} ${VAR} = ${VAL};

public ${TYPE} get${NAME}(){
return ${VAR};
}

public void set${NAME}(${TYPE} ${VAR}){
this.${VAR} = ${VAR};
}

${cursor}

Mine is named prop, so when I am in a Java file I type

prop

then press the TAB button/key. The template is expanded and asks me to fill in the details. Below are some screen samples of this in action.

I simply press the TAB button to jump between the fields TYPE,VAR, and VAL, enter the values, and when I have them all filled in press the ENTER button and my cursor is placed at the ${cursor} position or offset in the editor.

The final result is a read-write property with the source code all laid out nicely


To expand the function of the template is easy enough. I have one which adds the logic for property change events. I have it named eprop in my IDE.

private ${TYPE} ${VAR} = ${VAL};

public ${TYPE} get${NAME}(){
return ${VAR};
}

public void set${NAME}(${TYPE} ${VAR}){
${TYPE} lold${VAR} = this.${VAR};
this.${VAR} = ${VAR};
pcs.firePropertyChange("${VAR}",lold${VAR},${VAR});
}

${cursor}

It assumes you have an instance of java.beans.PropertyChangeSupport called pcs.

I have another one named ewprop which stands for Wrap or Wrapper, and in this case another field is needed to handle wrapping primitive types to pass the call to firePropertyChange, and it also assumes a variable named pcs:

private ${TYPE} ${VAR} = ${VAL};

public ${TYPE} get${NAME}(){
return ${VAR};
}

public void set${NAME}(${TYPE} ${VAR}){
${TYPE} lold${VAR} = this.${VAR};
this.${VAR} = ${VAR};
pcs.firePropertyChange("${VAR}",new ${WTYPE}(lold${VAR}),new ${WTYPE}(${VAR}));
}

${cursor}

That covers much of what one wants to do with beans.

One thing still missing from the pre 6.0 or 5.5 days is the ability to easily manage JavaBean patterns. This involves things such as being able to rename a property and have the field and method names change at once. The ability to add JavaBean properties has been added back to the IDE at least, but these code templates I'm writing about are easier to use, or at least quicker, than the UI to add properties through the Java editor once you are used to using them, but maybe that can be remedied by adding a quick pop up menu for doing things with JavaBean patterns to the Java editor; if I have time this year that can be one of my community contributions :-D

Who says a RootPane always has to be at the top?

Some friends and I have started a project to extend functionality inside the NetBeans RCP (Rich Client Platform). We call it PlatformX, and it is located on the web at http://platformx.netbeans.org. We hope to have the repository public soon for others to use and contribute.

One of the APIs I'm working on is called RootPaneTopComponent. For the uninitiated in NetBeans RCP, a TopComponent is a Swing component managed by the NetBeans platform. They may work as regular components or can also be used as dockable/undockable components which may be moved around in the application.

A RootPaneTopComponent is a TopComponent which implements the RootPaneContainer interface. It allows one to use a glass pane, a menu and menu items, or a layered pane in more component based classes such as JFrame, JInternalFrame, and JApplet do for the more encompassing classes, so this new class in PlatformX allows the same thing yet at a lower level.

I'll have more information as soon as possible about this class and its sister class CloneableRootPaneTopComponent when I get it finished and we are closer to having a more public release of our first Platformx APIs and repository access. Until now here are some simple screen shots.

Imagine you have a dockable component you need disabled or the ability to cover with some user blocking message until another application state has been reached, and you do not want to block the entire window or a dialog. This is where component level glass panes come in handy:

Now you see me:


now you don't:

and I'll leave it up to you to figure out ways you could use this in your applications today. I'm using it to block certain components which need the user to login to be able to use them.

I mentioned the menu bar. I have also coded this particular class to allow north, south, east, and west components to be placed around it. This could be used for multiple things. I have chosen in this example to imagine some type of an editor which might have search functionality and maybe a notes editor which could show different notes for paragraphs or diagrams or any thing else one might think of:

No notes showing:


and now they are:

Anyways, this is just a simple example to show some of the capabilities of what I'm working on at the moment. This entry is to make it easier to show the others working on the project how it works right now more than anything, but it can be a preview as well :-D. Hopefully it, along with some other things, will be released soon. It's NetBeans, so of course it is open-source.