Proposed feature set

Tabs

• 2d draw mode
• edit xml mode
• 3d mode with vtk

Toolbar

• Add lines/members
• mirror
• copy
• offset
• trim
• rotate
• ortho

Layers

Using VTK with java

• cd java/
• mkdir classes/
• javac -d classes/ vtk/*.java
• cd classes/
• jar cvf vtk.jar vtk/
• jar i vtk.jar
• cp vtk.jar ../../bin/
  

The goal is to build a kick-ass 3d renderer using vtk inside java. My guess is that I'll need the vtk.jar and the .dll (shared libraries) and tuck them inside NakedRelease/libraries and NakedRelease/native. But we'll see how well that works :)

http://www.duke.edu/~iwd/howto/VTK-Linux-Java_HOWTO.html


1) Build vtk4.x with Java wrapping

2) Compile all the vtk *.java files ... look in dir x:\vtk4x\VTKbin\java\vtk

3) compile vtkPanel.java and place it in java\vtk with the other classes ... look in x:\vtk4x\VTK\Wrapping\Java for the source file.

4) Add environment variable CLASSPATH = .;x:\vtk4x\vtkbin\java (NOTE: the leading period is important). Since vtk java wrappings have been packaged, you do not need to point to the \java\vtk folder, just \java

At this point you should have a good vtk Java wrapping installed so try running VTKSimple to make sure the Java part is working okay ... look in x:\vtk4x\VTK\Wrapping\Java for the source code.

5) edit MatLab C:\MATLAB6p1\toolbox\local\classpath.txt to add drive:\path_to_the_classfiles

Don't put the name of the classes there. Just the path is sufficient for matlab to pick up all the classes that exist in that directory. Since vtk java wrappings have been packaged, you do not need to point to the \java\vtk folder, just \java. For example, this works for me...

P:\WinCVS\vtk40\VTKbin\java

6) Compile the vtkMatlab.java file (see below for code) and place the class file in the java directory (important not in java/vtk) .... try placing it in x:\vtk4x\vtkbin\java. You could place this file whereever you want if you add its path to the MatLab classpath or to the Environment variable CLASSPATH see steps 3) or 5)

7) Run the testvtk.m script (see code below) which attemps to load each class from MatLab. It should run fine and create all the zillion variables. If some are not created check that in cmake you enabled all the needed modules (patented etc). As vtk changes you may need to recomplie the list of vtk classes it loads, see the instructions for doing this in the comments of the script.

7b) Alternately you can run my script ckvtk.m (see code below) which dynamically creates the list and objects, writing log files with a.) successful creations and b.) any errors creating objects. Intenal comments tell whats going on. Note: you need to change the path in the script to point to your directory of vtk classes so it can generate the class list. (I know I could probably get this from the CLASSPATH variable but I'm too lazy)

8) Run the cone.m script from within MatLab (see code below)

I was not able to run this with the default jre in Matlab (v1.1.8) so I changed to jre 1.3.1 as follows:
Create an environment variable MATLAB_JAVA and point it to the jre folder you want, for example P:\wincvs\java13102\jre. I see some funny things happen in Matlab with 1.3.102 but this might just be me. I've seen some seg faults and the Matlab command cursor disappears sometimes. Use at your own risk. Another funny thing is that exitting the vtk scripts closes MatLab...hmmmm

Also it appears that Matlab truncates class names longer than 31 characters (35 with vtk.) so these classes can not create objects using the standard obj = vtk.vtkClass however this works obj=javaObject('vtk.vtkClass')

Nicer java deployment

Here's my take on the nice java program deployment problem. It works nicely for me

• From Eclipse -> Export NakedSees.jar (with the manifest and jardesc files) in a folder called NakedRelease/classes
• Create two folders NakedRelease/libraries and NakedRelease/native
• Put swt.jar under libraries, and put .dll files under native folders
• Copy images folder to NakedRelease
  
• From eclipse, change the manifest file to

Manifest-Version: 1.0
Main-Class: nakedsees.swt.MainDisplay
Class-Path: ./libraries/swt.jar

• Right click on the jardesc file -> create jar -> yes to replace
• Check NakedSees folder into CVS (with manifest, jardes files, and the images dir)
• Download Marner java launcher -> copy Launch.exe and launcher.cfg into NakedRelease (to change icon of the exe, just recompile the sourcecode with vc++)
  
• Change Launch.exe to NakedSees.exe and launcher.cfg to NakedSees.cfg
• Copy the jre folder to NakedRelease -> copy javaw.exe into same directory and rename it to NakedSees.exe
  
• Change the .cfg file to look like this
  

classes
..\jre\bin\NakedSees.exe
-Djava.library.path=./native/ -jar nakedsees.jar

• Zip up NakedRelease and just let user unzip it

Or

• or dowload Nullsoft Install System and HM NIS Edit -> File -> New script from Wizard -> till finish and then compile everything to create a nice installer
  

nice swt deployment on windows

http://keyboardsamurais.de/node/63

Tutorial: Deployment of client side Java or Eclipse/SWT Applications on Windows

Submitted by tag on Sun, 05/16/2004 - 23:51.

When building a client side Java application, with whatever GUI Framework happens to be your favourite one (AWT, Swing, SWT - just to name the obvious triplet), at some point you really have got to ask yourself what would be the best way to distribute your app, without causing the end-user too much pain.

I think that most people would agree that customer acceptance depends to a large extent on the first impression of the user with the particular product. The first contact with your software however, typically is the installation procedure. With java software and the advent of so called "Platform independent" solutions various attempts to address installation facilities have been tried, but just too often, java coders tend to neglect this duty shamefully. Pretty often you find yourself with some classes and jar files you need to copy all over your system, add extensions to your classpath and finally launch the app from the command line via :java classname just to watch it fail a dozen times before you discover that you forgot to add the -Djava.library.path property to the command line (as stated in the readme.txt at line 1846).

The Installer
Windows users can be very choosey about standardized installation procedures, thus I would recommend using a native Windows Installer like the Nullsoft Install System to create an installer (i.e. a Setup.exe) for your application that can be installed and uninstalled properly in a standard, Windows way^tm. NSIS offers a pretty cool, powerful macro language for installers that you fortunately don't really have to learn to create your typical basic installer. For the average installer it is sufficient to use the really cool wizard option of the magnificent open source Installer editor HM NIS Edit by Hector Mauricio Rodriguez Segura and just take your setup.exe and go. You can easily build really complex installers with custom controls with this tool as well - sky's the limit.

Launching the app
Launching your java application is the next experience the user comes in contact with. If you choose to launch your application through some batch files or worse, let the user start the app through command line as mentioned above, you will most definitely burn in coder hell - and rightly so. There are quite a number of really useful java launchers out there that make launching a java app no less pain than a double click, though the application may actually have serious amounts of dependencies. My favourite one is the Marner Java Launcher by Jacob Marner. It is basically a small executable program written in C, that launches your java VM with all your previously configured options.

Let's assume following example: You wrote a small app that uses a couple of java libraries and utilises the Eclipse SWT framework for the GUI. Now you want the java launcher to do all your bidding. Your first step should be to create a folder at the root of your project directory called libraries and copy jface.jar, swt.jar and whatever libraries you desire into it. Also, you should copy the native SWT dlls into a separate folder called native. In our case this would be swt-awt-win32-xxxx.dll and swt-win32-xxxx.dll from the eclipse directory eclipse\plugins\org.eclipse.swt.win32_x.x.x\os\win32�. Now we have gathered our source code, the dependent libraries and the native components in one directory.

Now we should create a jar file from our source code that contains a file in the root directory called manifest.mf file. The manifest.mf file contains information which Class should be launched as an entry point into our application (i.e. which class contains the main() method. Also it adds our dependent libraries from the libraries folder to our classpath. The manifest.mf file should look like this:

Manifest-Version: 1.0
Main-Class: de.keyboardsamurais.ApplicationMain
Class-Path: ./libraries/xmlrpc-1.2-b1.jar ./libraries/jface.jar ./libraries/log4j-1.2.8.jar ./lib/swt.jar

Eclipse Users can use the "Export" feature for the jar packaging. Now we are able to call our class from the command line via the call java -jar application.jar. Well...almost! Our application still lacks the native DLL components, so we need to tell the VM where they can be found via a -D flag. We can enter java -Djava.library.path=./native/ -jar application.jar and our app should run flawlessly.
Now, that's the point where we configure the launcher.cfg file from our java launcher. For our example this config file would look like that:

.
javaw.exe
-Djava.library.path=./native/ -jar application.jar

If you do need an output window for log messages you can exchange javaw.exe for java.exe. You can now click on the Launcher.exe (which you should have copied into your project directory by now) and your application will run like a charm.

You can now wrap it all up into a nice installer and everybody will have a pleasant experience with your software deployment. You might want to change the icon of your launcher.exe to something more fitting. I recommend doing this with Resource Hacker by Angus Johnson.

Last words
Be aware that there are more than a few other options to do all of the above mentioned steps. One of the most promising install systems is Java WebStart and there are a couple of multi platform installers that promise "Write once, run anywhere". However I am quite happy with the above solution.

including jre with application

source

Deploying the JRE with your application is simple. The JRE on windows is usually saved on the hard drive in:

C:\Program Files\Java\j2re1.5.xx or something similar.

All you need to do is include that entire directory with your app and access the javaw command via a relative path from a .bat file or small .exe to start your app.

You should check the following link as it will show you how to oragnise your directory structure and you can download a free program which will give you a small .exe that will invoke the VM and start your app.

http://www.rolemaker.dk/nonRoleMaker/javalauncher/marner_java_launcher.htm

The whole directory containing your .jar/.class files and the JRE can then be zipped up and put onto to target machines or you could use any standard installer if it's going to be installed by non tech people.

Using this method you won't disturb the 1.4 java installation on the target machines. I deploy my apps this way.


source

The Marner Java Launcher

by Jacob Marner. (jacob@marner.dk)

---

Java is a great programming language, but it is generally somewhat complex for novice end-users to get the program up running. Traditionally they have to install a JRE, install any optional packages like Java3D, set the path environment variable and then start a batch file. This doesn't exactly seem professional to the Windows end-user, who generally just expect to be able to hit an icon or an .exe file to run. This launcher addresses this problem by providing you with a small .exe file that launches your Java application in a foolproof way, while making sure that it looks exactly like any other Windows application.

The advantages of this launcher over the traditional way are many:

• Users simply click an .exe file or shortcut to run the application.

• No need for users manually to install a JRE or any extra libraries.

• No need for users to set class path or path variables.

• Users will never know you used Java.

• No problems due to incompatible versions of Java already installed on the machine (mostly due to Microsoft's broken version) and this allows you to use non-standard JVM options such as setting heap size.

• There are no problems with using the launcher with autorun, various installers (such as InstallShield) or various third party libraries.

• It works with with any Java virtual machine no matter whether it are standard conforming or not. In fact it can be used to launch interpreters for languages such a Perl or Python, too.

• If you provide your own native DLL libraries you are sure that your versions of the libraries are loaded - not some duplicates present in a system library.

This program is open-source and is public domain. Use it for what ever you want. However, if you edit the code and redistribute it again then please do not call it the Marner Java Launcher and please credit me for my work.

Download Marner Java Launcher 1.22 (40 kb). (released 2003-9-9) (includes both binary and source)

See the included readme.txt file for instructions. Enjoy!

So how does it work?

It is very simple actually. The .exe provided loads a text file called launcher.cfg that tells it what program to start and with what parameters. It also allows you to set the directory of your Java root - this will be the current directory when Java starts. Then it starts the program you named and Java is running. Extremely simple but beautiful.

FAQ

Should I bundle a Java VM with my application?

Bundling a JVM with your applications is highly recommended. The only drawback is that it will take up 20 MB extra disk space (but that is nothing these days) and the distribution will be 6 MB larger. Several other Java launcher available do not support bundling of JVMs and will sometimes fail.

If you do *not* bundle a JVM the following will happen:

• You will have to assume that java.exe or javaw.exe is in the PATH or in the windows or windows/system directory. If not, the user will have to download and install it. Putting it in the path will not help if it is already present in the Windows directory since that always will be used over that in in your PATH.
• If the JVM already present is incompatible then your program will probably fail or run suboptimally.
• If you provide your own native libraries you cannot guarantee that they are run instead of any duplicate present in the windows system directory. If this happens you application will fail mysteriously or even crash.
• Users will have to know what Java is.

How do I create a desktop icon for my application?

Doing so is best done from an installer program like InstallShield. During install such program will create a icon to the program .exe and will also provide an uninstall feature for you.

If you package your program with, say, WinZip (possibly self-extracting) then users will have to click the .exe file to start.

How do I change the icon embedded in the exe?

To do this you have two options:

1. Recompile the .exe. The source code and project files for Microsoft Visual C++ can be found in the source directory. In Visual C++ just replace the icon with your own one and then recompile. Doing this requires no C++ knowledge but requires Visual C++.

2. Use some program that does just this. One such program is the shareware program IconForge.

How do I make sure that the native DLLs I provide can be found?

In the case you use some third party library written for Windows (such as my own libraries JWindows or 6DX for Java) you must be sure that those DLL can be found by the system and that no other DLLs with the same name is used instead.

To be sure that your own native DLLs can be found you must place them in one of the following directories:

• The current directory at the time the library is loaded.
• The directory with the executable you started via the Marner Java launcher. Since you often start java.exe or javaw.exe the directory will often be JRE\bin or something like that.

If you change the current directory during the execution of your program I recommend putting them in the JRE\bin directory.

Alternatively, if it is JNI based libraries you wrote yourself then you can place them wherever you want and the use System.load() instead of System.loadLibrary() to load them with an absolute path.

How do I change the name seen in the Windows Task manager?

If you start a Java application with this launcher and use say, javaw.exe then the Windows task manager will show that name. To change the name to your preferred one you need to change the name of javaw.exe. Take a copy of it into the same directory and then rename it to whatever you want. You should not just rename the old one without copying it first, since you then will be violating the license agreement with the JRE.

But I want to distribute my application as a stand-alone executable file. How do I do that?

Not with the Marner Java Launcher. You can use a static Java compiler instead. I recommend Excelsior Jet.

cvs notes

Set up repository

1. request account from sourceforge.net
2. download eclipse
3. login to cvs from eclipse and add your module (directory/project) to cvs
   

Terms

• checkout - get copies of project locally
• commit - put your changes on the server
• release - commit and delete local copy of files
  
• update - update your local copy of project if someone else has modified it in the meantime

Command Line

1. login to kepler
2. bash
3. export CVS_RSH=ssh
4. cvs -d:ext:sthapit@cvs-ssh.sourceforge.net:/cvsroot/nakedsees checkout NakedSees2

to check out VTK, follow steps 1, 2, and 3 and then do this

1. cvs -d :pserver:anonymous@public.kitware.com:/cvsroot/VTK login
   (respond with password vtk)
2. cvs -d :pserver:anonymous@public.kitware.com:/cvsroot/VTK checkout VTK
   

Setting up CVS on sourceforge

Steps to setup a new project with CVS on sourceforge

1. Download a SSH client
2. hostname: cvs.sourceforge.net
3. username: sthapit and port: 22
   
4. Protocol: :pserver: for anonymous CVS, or :ext: for developers (with SSH for external authentication; export CVS_RSH=ssh)
5. Repository Path: /cvsroot/PROJECTNAME

CVS

• CVS wiki
  
• Using eclipse with sourceforge and CVS
  
• http://www-mrsrl.stanford.edu/~brian/cvstutorial
• sourceforge intro to CVS
  

To Create an Executable SWT JAR

1. File -> Export -> Jar file
2. Select NakedSees and org.eclipse.swt
3. Choose jar file name -> Next
4. Check "Save description of this JAR in workspace" and pick a description name -> Next
5. Check "Save manifest in workspace"
6. Check "Reuse and save manifest in workspace" -> pick manifest name
7. Browse for "Main class" -> Finish
8. Copy swt.jar to same folder as jar file
9. Open manifest file in eclipse, and add "Class-Path: swt.jar"
10. Right click on the JAR description file and select "Create JAR" -> select "yes" to overwrite
11. Copy the swt DLL's and image files to the same folder as the JAR file
    

from another website
1. Make sure the SWT jar file is included in the Eclipse project build path
a. Download the standalone SWT jar file from eclipse.org even if you already have the ones that come with Eclipse. It is called swt.jar and you will package it with the executable JAR. Make sure it is the same version of SWT that you used to make your program.
b. In Eclipse, import swt.jar via Project Properties::Java Build Path::Libraries::Add External JARs. (Make sure to include the source .zip file). Also make sure to select the swt package in the Order and Export tab.
c. At this point, you should be able to compile and run your SWT application in the Eclipse SDK.

2. Do a standard Eclipse jar file export
a. Right click on the main .java project file and select Export.
b. Choose JAR File from the list.
c. Select the relevant packages and .classpath and .project resource files
d. Make sure Export generated class files and resources is selected and browse to the location where you want the JAR file to be created.
e. Specify Generate the manifest file and don’t seal the JAR or any packages. Choose the class containing the main method as the Main class .

3. Change the manifest file
a. Navigate to the JAR file you created and open it with WinZip.
b. Open the MANIFEST.MF file inside and copy the contents.
c. Create a new file called MANIFEST.MF and paste in the contents of the old manifest file.
d. Add the line Class-Path: . For simplicity, you can just keep a copy of the swt.jar file in the same folder as the executable jar, in which case, the line is Class-Path: swt.jar . Make sure there is a carriage return after the last line in the manifest file, or that line will not be parsed.

4. Replace the manifest file
a. Make sure the manifest file and the executable jar are in the same folder.
b. Open the command prompt and navigate to the containing folder.
c. Enter the command jar umf MANIFEST.MF to update the manifest file with the class path information.

5. Package the JAR with SWT files
a. Put the updated executable JAR file, swt.jar, and the associate DLL in the same folder. The DLL can be pulled out of swt.jar and should have a name like swt-win32-####.dll on Windows.
b. The JAR file should now successfully execute. On Windows, you can usually just double click the JAR file in explorer and it will open. If that does not work, the command java –jar on the command line has the same effect.

First Steps

Got my brand new ThinkPad T43. Yay. I quickly uninstalled the IBM JRE 1.4.1 and installed the Sun JDK 5.0. I also installed the eclipse IDE which is really slick and is running great so far. The goal is to use this to develop a GUI for OpenSees using SWT instead of the crap ass AWT or the memory hog Swing.

What is this you speak of?

The Naked System for Earthquake Engineering Simulation (NakedSees) is a self sponsored project to develop a graphical interface for OpenSees using Java. NakedSees is intended to maked it easy for users to use the popular OpenSees program. The core development team for the initial development of the project is me.