Testing NBM's for update center locally

When creating NBM's to be deployed for an update center NetBean's nicely create a list of NBM's and the corresponding update.xml file.

Now, when you would like to test those NBM's I often upload to a dev-area on my webserver to test the update. A faster way to check the consistency of the generated files is directly to enter a File URL in the the Settings for the Update Center.

An example of the syntax to use to read those update from a local Windows disk:

file:/C:/svn/trunk/myapp/build/updates/update.xml

As I was trying to launch a NetBeans RCP app from an external drive with a specific JRE also deployed on that external drive, I had a little trouble to also have the user directory located there.

My mistake was to have the user directory specified in the same directory as the RCP app.

Example: Assume you create a ZIP of your app called "MyApp". It will be in a folder called "MyApp" (The folder is containing "bin", "etc", and so on). To make sure it uises a given tested version of the JRE assume you also have a copy of the JRE in that deployment dir.

NOT WORKING :

set MYAPP=%~dp0
"%MYAPP%\bin\myapp.exe" --jdkhome "%MYAPP%\jre6" --userdir "%MYAPP%\myuserdir"


The code above will create the userdir but than just exit. I have no explanation for this behavior. What solved the problem is to make sure the user directory is not under the deployment directory

WORKING:

set MYAPP=%~dp0
"%MYAPP%\bin\myapp.exe" --jdkhome "%MYAPP%\jre6" --userdir "%MYAPP%\..\myuserdir"


Which put the user directory parallel to the deployment directory.

Oracle is going full speed NetBeans

From this link (Ted Farrell, Chief Architect and Senior Vice President about Oracle + Sun Java Developer Tools Strategy) I can only positively conclude that Oracle is putting its eggs into NetBeans - including the NetBeans Platform - Great news !

Missing rt.jar Mac OS X using ProGuard with NetBeans

When you are using ProGuard for obfuscation of some of your NetBeans module code on a Mac running OS X and you will most likely refer to rt.jar in your build.xml and get and error about missing rt.jar.

One quick fix solving this could be the following which helped me.

On your Mac open a terminal and change directory to

/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib

now just softlink to classes.jar via

me$ sudo ln -s ../../Classes/classes.jar rt.jar

Visual Library Website moved

After the migration of all NetBeans sites we now have

http://graph.netbeans.org is now http://platform.netbeans.org/graph

Visual Lib and Widget Locations after resize

After a longer (rather frustrating) debugging I have found a way to fix what is mentioned under http://www.netbeans.org/issues/show_bug.cgi?id=173997 (see at the end of this issue a test app)

The key to success here is to ignore whatever is returned by the widget.getPreferredLocation() and only focus using the widget.getPreferredBounds().

As David (father of Visual Lib) nicely reminded me about we have the view/scene/local coordinates are described at:

http://bits.netbeans.org/dev/javadoc/org-netbeans-api-visual/org/netbeans/api/visual/widget/doc-files/documentation.html#CoordinationSystem

but even though the coordinates are getting somehow mixed up and the only safe way is to ask for the getPreferredBounds() and than convert those to the Scene coordinate system.

Dynamically change color of Node icon(2)

I blogged about the way to change the color of an icon dynamically here. Now, I have encountered that when I add those icons to a list of nodes or menu items, all icons get the color of the last one changed. Hmpf.

It looks like that ImageUtilities.loadImage(..) somehow caches the icon and hence even when assuming working on a new copy we still work on the common one.

The way I got it working was to forcefully create a new BufferedImage and merge in the one just loaded. The new code looks like this



private BufferedImage icon16;
private BufferedImage icon32;
public static final String PROP_ID = "id";
public static final String PROP_NAME = "displayName";
public static final String PROP_COMMENT = "comment";
public static final String PROP_COLOR = "color";
public static final String PROP_ICON16 = "icon16";
public static final String PROP_ICON32 = "icon32";

// ...

public Image getSmallImage() {
int width = icon16.getWidth();
int height = icon16.getHeight();

BufferedImage newImage = new BufferedImage(width,height,BufferedImage.TYPE_4BYTE_ABGR);
newImage = (BufferedImage)ImageUtilities.mergeImages(icon16, newImage, 0, 0);

for (int x = 0; x < width; x++) {
for (int y = 0; y < height; y++) {
int rgb = newImage.getRGB(x, y);
if (newImage.getRGB(x, y) < 0) {
rgb = some_method_returning_the_RGB_for_a_selected_color;
newImage.setRGB(x, y, rgb);
}
}
}
return newImage;
}

// ...

private void loadIcons() {
String iconId = props.getProperty(PROP_ICON16);
icon16 = (BufferedImage)ImageUtilities.loadImage(iconId);
iconId = props.getProperty(PROP_ICON32);
icon32 = (BufferedImage)ImageUtilities.loadImage(iconId);
}




And it now respects each individual color.