Merge branch 'master' of http://scm.trinitydesktop.org/scm/git/tde-packaging

1 files changed, 64 insertions, 0 deletions

diff --git a/ubuntu/maverick/tdebindings/debian/libqt3-java-trinity.README.Debian b/ubuntu/maverick/tdebindings/debian/libqt3-java-trinity.README.Debian
new file mode 100644
index 000000000..bfba13c88
--- /dev/null
+++ b/ubuntu/maverick/tdebindings/debian/libqt3-java-trinity.README.Debian
@@ -0,0 +1,64 @@
+Developing and using Qt based applications written in Java
+==========================================================
+
+This document explains how to develop and use Qt based programs
+written in Java.  This is what the Qt java bindings from the package
+libqt3-java are designed to accomplish.
+
+Firstly, the bindings should work with any java compiler and VM
+properly implementing the JNI interface, but they have only been
+tested with the GCJ compiler and GIJ interpreter from the GCC suite.
+Note that the bindings are not compiled to native code, using GCJ's
+unique capability to do this, they are simply compiled to .class
+files, and interpreted, in the classical Java manner.
+
+Secondly, when compiling and running apps using the Qt Java bindings,
+you need to add "/usr/share/java/qtjava.jar" to the CLASSPATH.  E.g.
+
+	export CLASSPATH="/usr/share/java/qtjava.jar:/usr/share/java:."
+	javac Whatever.java
+	java Whatever
+
+And, that's basically the hard part of it all.  For the rest,
+developing Qt Java apps is much like Qt C++ apps, except that working
+with slots is easier, and compiles may be faster as well.  The API
+should be completely similar to the Qt C++ API, so the standard Qt
+docs should translate pretty easily.  There are a lot of Qt Java usage
+examples in /usr/share/doc/libqt3-java/examples.
+
+If you're interested in developing KDE applications using Java, look
+at the libtrinity-java package.
+
+
+Generating native executables
+-----------------------------
+
+It is also possible to produce native executables with the following gcj
+invocation:
+
+	export CLASSPATH="/usr/share/java/qtjava.jar:/usr/share/java:."
+	gcj -fjni Somefile.java /usr/share/java/qtjava.jar --main=Somefile
+	LD_LIBRARY_PATH=/usr/lib/jni ./a.out
+
+As this will compile the full qtjava.jar into native code, the resulting
+executable will be rather large. If you plan on having several of these
+executables, it may be worth creating a shared qtjava library, like
+this:
+
+	gcj -fjni -shared /usr/share/java/qtjava.jar -o libqtjava-shared.so
+
+And then, after you put libqtjava-shared.so in /usr/lib or similar, you
+can go like:
+
+	gcj -fjni Somefile.java --main=Somefile -lqtjava-shared
+	LD_LIBRARY_PATH=/usr/lib/jni ./a.out
+
+In the future, I'll investigate the possibility of shipping the
+qtjava-shared library in the Debian packages.
+
+Also, in order to avoid the necessity of setting the LD_LIBRARY_PATH
+environment variable, the option -Djava.library.path=/usr/lib/jni can be
+passed to the gcj invocation. There is, however, a bug [1] in gcj that
+prevents this from working, and it's only fixed in gcj-4.0.
+
+    [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18234