java-gnome 4.0.9 (13 Oct 2008) ============================== _The pen is mightier than the sword_ New coverage ------------ This is the first release with coverage of GTK's powerful TextView/TextBuffer multi-line text display and editing Widget. This has been the result of several months of careful effort to present a clean and self-consistent API while remaining faithful to the underlying implementation. This bulk of this work was done by Stefan Prelle and Andrew Cowie, with contributions from Kenneth Prugh and testing by many people in the `#java-gnome` community. * **`org.gnome.gtk.TextBuffer`** * **`org.gnome.gtk.TextIter`** * **`org.gnome.gtk.TextTag`** * **`org.gnome.gtk.TextTagTable`** * **`org.gnome.gtk.TextView`** * **`org.gnome.gtk.TextWindowType`** The snapshot at right is from [`ExampleInstantMessenger`](doc/examples/textview/ExampleInstantMessenger.html), included with the sources. It is a somewhat detailed example showing the use of TextView, TextBuffer, and related classes. Try running it! Other improvements ------------------ Continuous improvement to various classes, especially in our documentation. Incremental changes have occurred in a number of places. In the TreeView/TreeModel APIs, some useful methods for translating TreeIters from one model to another have been added. * **`org.gnome.gtk.TreeModelSort`** * **`org.gnome.gtk.TreeModelFilter`** Also thanks to the persistent work of Stefan Prelle, we have nice coverage of GTK's Assistant (aka druid, wizard, etc): * **`org.gnome.gtk.Assistant`** Better support for doing popup context menus, including some bug fixes. Thanks Srichand Pendyala for taking care of this and to Owen Taylor for having explained out some of the underlying implementation details. * **`org.gnome.gdk.EventButton`** * **`org.gnome.gtk.Action`** * **`org.gnome.gtk.TreeView`** * **`org.gnome.gtk.Widget`** And, as usual, incremental improvements to core classes, notably a few new signals here and there. Virtually every class has been touched in one way or another; most changes are cosmetic but they add up to significant contribution. Reducing memory pressure ------------------------ Internally, java-gnome maintains a lookup table so that pointers coming from the C side can be converted into proxy objects for the case where a proxy has already been created. In any library there a great number of transient and temporary objects and structures allocated, and we are no different. It turned out that registering these temporary objects was putting pressure on the lookup table. While these objects _were_ properly weak referenced and being garbage collected (and thence freed), there were nevertheless an enormous number of temporary objects being inserted and removed from the lookup table -- and that sort of thing causes hash tables to grow overly large. To do something about this we have split the former hierarchy root into two classes. Only structures which have a persistent identity (which, in practise, means only GObjects and certain Cairo entities) are registered so they can be looked up by address later as necessary. These remain subclasses of the former root `Proxy`. The rest of the Java side proxies for are now subclasses of `Pointer` which is now the new root for our class hierarchy. These _aren't_ registered, essentially eliminating the transient pressure on the lookup table. * **`org.freedesktop.bindings.Pointer`** * **`org.freedesktop.bindings.Proxy`** * `org.freedesktop.bindings.Plumbing` * `org.freedesktop.cairo.Entity` * **`org.gnome.glib.Object`** * `org.gnome.glib.Plumbing` * **`org.gnome.glib.Boxed`** This is entirely an internal change. Users of released & packaged versions of the library will not notice any difference. Developers and hackers who have a checkout of the project source code may need to `make clean` if they haven't since `'mainline'` revno 567. Thanks to Vreixo Formoso for doing the bulk of the leg-work on this one. Making it easier to run java-gnome programs ------------------------------------------- Because java-gnome is directly binds to underlying system libraries, it has a native shared library component. This led to the usual development hassle of having to specify where this library is to be found if it were anywhere other than `/usr` and of course the nightmare of ensuring a VM used the right library in the event you were developing against or hacking on a newer version of java-gnome; in Java this meant: $ java -classpath /opt/local/share/java/gtk-4.0.jar:. -Djava.library.path=/opt/local/lib com.example.Program No longer! The native shared library part of java-gnome is now located deterministically and loaded automatically. You don't need to faff about with `java.library.path` on the command line or in your IDE any more! $ java -classpath /opt/local/share/java/gtk-4.0.jar:. com.example.Program Our native component is completely coupled to the specific release you are using, so sufficient version information is embedded in the `.so` name to ensure that the right library (and only the right library) is loaded. There are _no_ changes if you are simply working against an "in-place" development build of java-gnome, be it from command line, or in an IDE like Eclipse, things will Just Work™; again, no `-Djava.library.path`: $ java -classpath ~/workspace/java-gnome/tmp/gtk-4.0.jar:. com.example.Program Note to downstream packagers: running `make install` is now **compulsory**. This signals a build that it is no longer being used "in-place" but instead is to be prepared for installation to a system prefix (Gentoo got bit by this; hooray for downstream packagers testing release candidates!). If you need to change the install locations, you can specify overrides when you run `./configure`, perhaps: $ ./configure prefix=/usr jardir=/opt/share/java libdir=/usr/lib/jni The defaults are all sensible, of course, and are as described in [README](README.html). Build system improvements ------------------------- Serkan Kaba has contributed a number of internal improvements allowing the top level `./configure` script to be precise about the versions of various GNOME dependencies we require. With the release of GTK 2.14, various bits of the underlying libraries have been deprecated. Thanks to the hard work from Serkan Kaba and new contributor George McLachlan, java-gnome correctly builds against GTK 2.14 without any problems. Note that java-gnome releases do _not_ set `GTK_DISABLE_DEPRECATED` (this is a change from 4.0.8); thanks to Mart Raudsepp of the Gentoo Linux desktop team for pointing out why this would be better. These macros _are_ still enabled for builds checked out from version control so hackers working on the bindings so will be able to keep up with ensuring we react to future deprecations (it's always awesome when downstream is a part of the upstream community; Serkan and Kenneth are also Gentoo packagers, and take care of the java-gnome `.ebuild` for us). Incidentally, the version constants identifying the library are now alongside the rest of the infrastructure. Public methods are now available if you want to use the API or release version number in a snapshot or example. * **`org.freedesktop.bindings.Version`** Looking ahead ------------- We're pretty happy with the state of the java-gnome right now. Coverage of the most important parts of GTK are in place. Our treatment of the underlying drawing library, Cairo, still has a bit to go, but the basics are there and a firm foundation to build from. More interesting are the remaining areas; the more general GNOME utility libraries and other parts of the Free Desktop stack that might be needed by an end-user application. It'll be interesting to see how these areas evolve in the coming months. AfC Lorem ipsum =========== A major concentration of effort over the last few months has been to write appropriate public coverage to present GTK's powerful but complex TextView/TextBuffer API, a Widget for presenting multi-line text and the backing store for manipulating it. The '`textview`' branch where this work has been taking place has finally been merged to '`mainline`'. As this development cycle continues we will continue to review and refine the API we're presenting, but this is nonetheless a significant milestone and one we're justly proud of. Thanks to Stefan Prelle for having done much of the leg work and also to Kenneth Prugh for his support during testing. You can read the API documentation for [TextBuffer][] and [TextView][] if you're interested in how things are shaping up. AfC [TextBuffer]: doc/api/org/gnome/gtk/TextBuffer.html [TextView]: doc/api/org/gnome/gtk/TextView.html