java-gnome 4.0.9



       Module: java-gnome
      Version: 4.0.9
  Uploaded by: Andrew Cowie

http://download.gnome.org/sources/java-gnome/4.0/java-gnome-4.0.9.tar.gz
  md5sum: 77ee839fd22b72a3f846bab21d55c19d
 sha1sum: 22d69dbdd1423c64a23a0dbf4ef46f28b21736aa
    size: 692K

http://download.gnome.org/sources/java-gnome/4.0/java-gnome-4.0.9.tar.bz2
  md5sum: 112316596312c260a5465004fd0fc3cf
 sha1sum: a226b616fc7fe9d7fc5b4be90c667f2a798a3715
    size: 504K

News
----

<a name="4.0.9" id="1223889576" title="Text APIs and better running!"></a>

java-gnome 4.0.9 (13 Oct 2008)
==============================

_The pen is mightier than the sword_

New coverage
------------

<img src="doc/examples/textview/ExampleInstantMessenger.png" alt=""
style="float: right; text-align: right; padding-left: 15px;" /> 

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&trade;; 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

<a name="textview" id="1219892996" title="Text rendering"></a>

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

-- 
An RSS 2.0 feed of ftp-release-list is available at:
http://download.gnome.org/LATEST.xml


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]