Fifty years experience in all facets of software development (design, coding, testing, systems engineering, management). usage of many languages (microcode, assembly, Fortran, RatFor, Pascal, Modula, Ada, C). Now retired and starting to learn the Java Platform as a fun exercise. I have always been a computer science Geek. Ann has posted 1 posts at DZone. View Full User Profile

Fixing Generated NetBeans Desktop Shortcut Icons

01.23.2013
| 3061 views |
  • submit to reddit

For some time I have been working with Geertjan Wielenga in order to brand a golf scheduling program that I wrote using Windows, the NetBeans Platform, and Java. I made liberal use of: 

http://platform.netbeans.org/tutorials/nbm-nbi.html

https://blogs.oracle.com/geertjan/entry/icons_for_netbeans_platform_applications

...as well as advice received via email. After some time, Geertjan informed me that he was unable to duplicate my problem. The problem was that no matter what I did, the desktop shortcut icon would be the NetBeans one (the orange NetBeans icon) instead of my application icon. No matter what I tried, the desktop icon would be OK on my development machine and wrong on my deployment machine. The deployment machine has no Java or NetBeans development applications installed. Geertjan could not reproduce my problems. I continued to experiment.

I have been learning the NetBeans Platform and Java on my own, therefore I decided that the problem was probably a configuration one. After many trials, I discovered how to get the desktop icons on both the deployment machine and the development machine to be mine. This article summarizes the results.

Using the following process results in success. My "application branding title" is "RoundRobin" (defined on the Basic tab reached by right clicking on the project and then selecting Branding).  My "application branding name" is "roundrobin" (reached by right clicking on the project, selecting Properties, and then Application). In the text that follows these values are used.

  1. On the development computer, uninstall the application if it has been already installed.
  2. In the c:\users\username directory delete the sub-directory .roundrobin-installer (notice the dot). Be sure the uninstall is done first since once this directory is deleted the uninstall will not work and the application has to be uninstalled using the  CMD window with administrator privileges. For my user account (Ann Maybury) I delete C:\Users\Ann Maybury\.roundrobin-installer.
  3. Use the IDE to repackage the application.
  4. Close the IDE.
  5. Install application from dist directory--and now the desktop icon is OK.
  6. Move installer the deployment machine (I used a flash drive).
  7. On the deployment machine, uninstall the application if it is already there and remove the .round robin_installer sub-directory.
  8. Install the application.
  9. The deployment desktop icon is now the same as the development icon

I have tested this process on two Windows7 computers using both the "replaceVistaIcon" documented by Geertjan in the tutorial and the original NetBeans icons created at NetBeans install time. Since they both work, I see no need to be dealing with the "replaceVistaIcon" process.

Icons have been a key component of the user experience ever since Xerox invented the system.  Users are conditioned to identifying programs by their icons. The process outlined above is fine for development types, but poor for the average user. I therefore make the following recommendations to the Netbeans Platform team.

  1. I believe that the IDE needs to delete the user .appName _installer file. located at c:\User\someAccount\.appName-installer as the last step in every uninstall. Asking a user to do this is just too technical for the average user.
  2. I also believe the uninstall should run whenever the user tries to re-install an application.  If the user is re-installing, it is sensible to assume that he wants to replace his older installation.  
  3. Geertjan's tutorial successfully let me embed the JVM in my application so that the user does not have to install Java. However, this solution has a disadvantage. The developer has to remember to update the embedded JVM whenever Java changes. Failure to remember would result in unforeseen errors caused by bad configurations. I think the Basic Branding screen should have a check mark for include JVM in installers. In this way developers could be sure that their software will run on the right Java when deployed.
Published at DZone with permission of its author, Ann Maybury.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)