NEWS

<a name="4.0.4" id="1190798858" title="Coverage increasing"></a>

java-gnome 4.0.4 (26 Sep 2007)
==============================

_Coverage increasing!_

Most of our work continues to be on infrastructure and architecture, improving
the code generator that outputs the translation Java layer and JNI C layer
which allow bindings hackers to reach the underlying native libraries.
Nevertheless, there have been a number of publicly visible improvements across
the board, so we wanted to push out a release highlighting these contributions!

Documentation improvements
--------------------------

Continuing our effort to have extensive developer friendly tutorial style
documentation, there have been major additions to a number of existing classes.
Of particular note is the Window class, containing the various utility methods
used to ask the window manager to do things for you (we've also started
exposing some of the deeper parts of the GTK toolkit, though only a few things
that were immediately related to window management).

* **`org.gnome.gtk.Window`**
* **`org.gnome.gtk.Widget`**
* **`org.gnome.gdk.Screen`**
* **`org.gnome.gdk.Window`**

While the topic of thread safety was discussed at considerable length in the
last release, we have added some of the more relevant information to the code
documentation to reinforce its importance.

* **`org.gnome.gdk.Gdk`**'s `lock`

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

Numerous people have been hard at work developing new coverage. The standards
for accepting patches which expose public API are high, so it's awesome to see
bundles accepted for being merged to `mainline` from new contributors Thomas
Schmitz, Wouter Bolsterlee, and Nat Pryce.

The infrastructure for a number of areas important to supporting applications
including Menus, Toolbars, and Actions has been put in place:

* **`org.gnome.gtk.Toolbar`**
* **`org.gnome.gtk.ToolItem`**
* **`org.gnome.gtk.ToolButton`**
* **`org.gnome.gtk.ToggleToolButton`**
* **`org.gnome.gtk.MenuToolButton`**
* **`org.gnome.gtk.SeparatorToolItem`**
* **`org.gnome.gtk.MenuItem`**
* **`org.gnome.gtk.CheckMenuItem`**
* **`org.gnome.gtk.SeparatorMenuItem`**
* **`org.gnome.gtk.Action`**
* **`org.gnome.gtk.ActionGroup`**

A number of Container related Widgets have been added, though coverage is
preliminary. There have, of course, also been a number of minor improvements in
other existing classes, including:

* **`org.gnome.gtk.Notebook`**
* **`org.gnome.gtk.ScrolledWindow`**
* **`org.gnome.gtk.Misc`**
* **`org.gnome.gtk.ButtonBox`**
* **`org.gnome.gtk.HButtonBox`**
* **`org.gnome.gtk.VButtonBox`**
* **`org.gnome.gtk.Label`**

and even:

* **`org.gnome.gtk.StatusIcon`**

Along with these goes a variety of miscellaneous constants and wrappers around
the stock item identifiers:

* **`org.gnome.gtk.Alignment`**
* **`org.gnome.gtk.ImageType`**
* **`org.gnome.gtk.ButtonBoxStyle`**
* **`org.gnome.gtk.Justification`**
* **`org.gnome.gtk.Orientation`**
* **`org.gnome.gtk.Stock`**
* **`org.gnome.gdk.Gravity`**

Internals
---------

Vreixo Formoso carried out an important refactoring to the type database and
Generator family of classes in the code generator, with the result that more of
the array passing and out-parameter cases are now being handled correctly. This
kind of work is usually thankless and taken for granted, but it's hugely
appreciated!

The real gains are in internal quality. A number of serious bugs and
limitations have been overcome (`Glade` is working again, for example). The
generated code now guards against improper use (you can't pass a `null` pointer
unless it's allowed by the underlying library). Related to this is handling of
"`GError`" -- Java side, bindings hackers will get `GlibException` which they
can then re-throw as an appropriate Java Exception, say `FileNotFoundException`
in the case of not being able to open a file.

This all goes along with numerous build system fixes by Srichand Pendyala to
make for an increasingly robust project. Thanks guys!

Looking ahead
-------------

As mentioned above, we have mostly been focused on areas other than public API,
but it is expanding steadily. The hard work on infrastructure, however, is
starting to pay off, and the next release should include coverage of TreeView,
GTK's powerful but complex list Widget.

AfC

<a name="gentoo" id="1187677072" title="Packaged in Gentoo Linux"></a>

Gentoo packages
===============

The java-gnome bindings suite is now available in [Gentoo
Linux](http://www.gentoo.org/). An `.ebuild` for 4.0.3 has been merged to
Portage in

 * `dev-java/java-gnome`

If you need help installing it, see the the Gentoo page in the 
[download](/4.0/get/gentoo.php) section here.

Thanks to the people who pushed this through: Xerces MC for having submitted an
initial `.ebuild`, Petteri R&#228;ty (Gentoo dev and Java team lead) for having
fixed it up, and Christoph Brill for testing.

AfC

<a name="4.0.3" id="1185883828" title="Code generator landed"></a>

java-gnome 4.0.3 (31 Jul 2007)
==============================

_The code generator has landed!_


Work has been underway for several months to develop the next stage of the new
java-gnome: the code generator that will output the tedious translation and
native layers that allow us to glue our public API to the native GNOME
libraries. With this release we're pleased to announce that the code generator
is a reality!

Generated translation and JNI layers
------------------------------------

The primary goal of the java-gnome 4.0 re-engineering effort has been to switch
to an architecture whereby we could _generate_ the bulk of the machinery
necessary to take make native calls into the GNOME libraries from Java.

Extensive prototyping was done to establish the detailed design and to validate
the architecture we had developed. Releases 4.0.0 through 4.0.2 contained this
work along with mockups of the "translation" layer (the Java code that
downshifts from our Proxy objects to primitives suitable to pass over the JNI
boundary, along with the `native` declarations necessary in order to call
methods actually written in C) and of the "JNI layer" (the C code that
implements the methods declared in the translation layer which in turn coverts
parameters into GLib terms and then makes the actual function call into the
appropriate GNOME library).

With a solid foundation proving that our design was sound, we subsequently
began the long effort to implement a code generator which would output these
Java and C layers, allowing us to replace the `mockup/` directory and at last
leave behind the shackles of entirely hand written bindings. Over the past five
months, the java-gnome hackers have been steadily working on the 'codegen'
branch. The nature of the challenge meant that we had to have most of the code
in place before any of it would be useful -- never an enviable task to be
working on. Thanks to the hard work of Andrew Cowie, Vreixo Formoso Lopes, and
Srichand Pendyala, we reached the point  where the output Java code compiled in
May, and the output C code successfully compiled in by the end of June.
Tremendous.

We've been bug hunting and refining since then, pushing towards the point where
we could merge back to 'mainline', at last replacing the hand written mockup
code. We are today pleased to announce the culmination of that work with the
release of java-gnome 4.0.3.

_This post on the [development of the java-gnome code generator][codegen]
contains further details should you be interested; the file
[5a-Architecture.txt][architecture] in the `doc/design/` directory of the
source code explains the rationale and origin of the engineering design._

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

Although our focus has evidently been on getting the generator into working
order, there have nevertheless been a few minor coverage additions along the
way:

* **`org.gnome.gtk.Entry`**
* **`org.gnome.gtk.Separator`**
* **`org.gnome.gtk.HSeparator`**
* **`org.gnome.gtk.VSeparator`**
* **`org.gnome.gtk.Frame`**
* **`org.gnome.gtk.Calendar`**
* **`org.gnome.gtk.Notebook`**
* **`org.gnome.gtk.Image`**
* **`org.gnome.gtk.Menu`**
* **`org.gnome.gtk.MenuBar`**
* **`org.gnome.gtk.MenuItem`**
* **`org.gnome.gtk.ToggleButton`**
* **`org.gnome.gtk.CheckButton`**

which are largely to the credit of Sebastian Mancke for having submitted them
and Srichand Pendyala for having fixed up their JavaDoc. There have also been
steady improvements to a number of other classes; notably further signals and
utility methods exposed in:

* **`org.gnome.gtk.Widget`**
* **`org.gnome.gtk.Container`**

along with some preliminary coverage of the lower level GDK event machinery:

* **`org.gnome.gdk.Event`**
* **`org.gnome.gdk.EventType`**

As is reasonable given our focus on writing the actual translation and JNI
layer generators, most of these present only one or two methods from the
underlying native class. Coverage will steadily improve as people contribute
their knowledge and experience in documentation form.

_People upgrading from 4.0.2 will actually notice that there are stubs for
**all** of the public API classes; this was necessary to make the generated
code compile. Most of these are empty as yet._

GList and friends
-----------------

`GList` and `GSList` are the native GLib data structures used to represent
lists and are the return type from quite a few methods across GTK. Vreixo
Formoso Lopes worked out how to handle and working our wrap/unwrap functions
for us to use in the JNI layer made a significant contribution to reducing our
blacklisted method count.

Flags
-----

We've also worked out handling of native types that, while type defined as
enums, are actually bit fields. These are used occasionally in GTK to express
options; two examples now exposed are:

* **`org.gnome.gtk.CalendarDisplayOptions`**
* **`org.gnome.gdk.WindowState`**

Flags subclasses present an `or()` function allowing you to combine individual
Flags constants into a new composite Flags object. Yes it's a lot of machinery
to do a logical `|`, but being strongly typed is a hallmark of java-gnome.

Build improvements
------------------

No release would be complete without mentioning that the code builds on more
systems than it did before! Thanks to Maciej Piechotka and Srichand Pendyala
for fixing problems resulting from Debian and Ubuntu strangeness.

The build internally now uses an optimized script that takes into account that
even though the code generator may have run the translation and jni files may
not actually be different. This was causing problems as Make only looks at file
modification time. Instead, `build/faster` (great name, huh?) will only rebuild
a target when source contents have changed. This was necessary for bindings
hackers working in Eclipse; every time a file was saved Eclipse would merrily
spawn off an auto-build which sooner or later would block the IDE UI. Yuk.
Addressing this has also resulted in a faster build for everyone; all good.

The internal build script _should_ be transparent; you still run `./configure`
and `make` as before. If you experience problems let us know.

Thread safety
-------------

In addition to the code generator, java-gnome 4.0.3 incorporates a
comprehensive thread safety strategy. 

None of the major Java graphical toolkits out there let you make GUI calls from
threads other than the "main" one; they're all single threaded. Even if all you
want to do is a quick worker thread to carry out some input validation in the
background after the user presses "OK", you have to jump through horrific
contortions to do so safely, resulting in cumbersome, clunky code.

By contrast, the new Java bindings of GTK presented in java-gnome are
**transparently thread safe**, the first and only graphical user interface
widget toolkit for Java to be so! We integrate properly with the underlying GDK
thread lock and as a result you can safely make calls to various GTK methods
from worker threads! This has been a long sought after goal and we hope a
significant contribution to helping developers write elegant code.

Every call made to the native libraries is protected by entering the "GDK lock"
[that's `gdk_threads_enter/leave()` for those familiar with the C side of
things]. The lock used is actually a Java side `synchronized` monitor and
therefore reentrant; nested calls all behave properly. When in a signal handler
callback the GDK lock is already held (you're "in" the main loop when a
callback happens), but since it just works transparently you don't need to
worry about it. If you do find a need to take the lock into account explicitly
in your own code, see `Gdk.lock` in `org.gnome.gdk`.

_It is worth noting that we have been warned that there are certain to be
places in the underlying libraries that do not yet live up to the requirements
of the GDK threads model -- thus we will likely end up tripping over such
things as we slowly add API coverage. We regard such inevitable instances as an
opportunity to help contribute to improving the stability of the underlying
libraries and will actively work with their maintainers to identify and resolve
such issues. Nevertheless, in testing thus far our multi-threaded use of GTK
has been rock solid. See these posts on [GTK thread
"awareness"][gtk-thread-awareness] and [java-gnome's thread
strategy][java-gnome-thread] if you wish further details on our approach to the
thread safety question._

Thanks in particular to Owen Taylor for having helped us navigate these waters!

Looking ahead
-------------

Taken together, these innovations represent the culmination of an immense
amount of work towards realizing java-gnome as a viable platform for GTK and
GNOME development.

Obviously with the generated translation layer in place the opportunity at last
exists to start dramatically improving our coverage level, and we welcome
contributions to this end. Prospective hackers are cautioned, however, that
simply wrapping generated methods is insufficient -- public API will only be
added when it is clearly documented and meets the [approachability][objectives]
criterion.

There are still areas where the code generator needs to be improved; we need to
improve our handling for arrays, lists, and out-parameters -- there are
numerous permutations with all sorts of ugly corner cases.

Now that Free Java with support for generics is becoming widely available,
4.0.3 will be the last release holding the language level to Java 1.4; starting
the next cycle 1.5 will be the minimum language requirement and we will be
leveraging generics and other 1.5 features from here on.

Most importantly, the primary focus of the next few months will be developing a
quality binding for the backbone of many applications: the `TreeView` Widget
and the underlying `TreeModel` which powers it. The APIs in the native library
is hideously complicated and has long been the source of confusion and pain for
developers in C; it has long been a major goal amongst the java-gnome hackers
to present a public API with as friendly and usable an interface as possible.
It'll be a good challenge.

AfC

[architecture]: /4.0/doc/design/5a-Architecture.html
[codegen]: http://research.operationaldynamics.com/blogs/andrew/software/java-gnome/code-generator-cometh.html
[objectives]: /4.0/objectives.php
[gtk-thread-awareness]: http://research.operationaldynamics.com/blogs/andrew/software/gnome-desktop/gtk-thread-awareness.html
[java-gnome-thread]: http://research.operationaldynamics.com/blogs/andrew/software/java-gnome/thread-safety-for-java.html


<a name="4.0.2" id="1171283501" title="End of the beginning"></a>

java-gnome 4.0.2 (12 Feb 2007)
==============================

_The End of the Beginning!_

Major bugfixes and refactorings
-------------------------------

Setting and getting properties on GObjects requires some tricky manoeuvring.
We implemented the code to do this early on, and it looked like our general
mechanism for getting Proxy instances for arbitrary pointers was working  fine
for properties. It turns out, however, that when you call `g_type_name()` on a
GValue _containing_ a GObject, it returns the name of the type that was listed
when the property specification was registered, rather than saying it is a
GValue (as you might expect) or what the object actually is (that you might
_also_ reasonably expect).

This led to all kinds of nastiness since the type name was what we were using
in our `instanceFor()` mechanism to discriminate (on the Java side) what kind
of Proxy subclass to create. The example we tripped over was asking for the
parent property of a Button packed into a VBox. What `g_type_name()` told us
was "GtkContainer", not "GtkVBox"! And that was a big problem, because
Container is abstract, and besides, we want to instantiate a concrete VBox
Proxy, not a Container one!

Solving the problem involved major changes to:

 * **`org.gnome.glib.Value`**
 * **`org.gnome.glib.Object`**
 * `org.gnome.glib.Plumbing`
 * `org.gnome.glib.GValue`
 * `org.gnome.glib.GObject`

The solution basically boiled down to having two separate code paths: one
named `objectFor()` [a greatly simplified version of the previous
`instanceFor()`] which returns normal Proxy objects for GObject subclasses
(Buttons and Labels and whatnot), and a new code path available via
`valueFor()` to specifically return our GValue Proxy for the cases where we
know we're getting a GValue back. Since that occurs in limited and known
circumstances only (ie, when we're getting properties) it's no problem to know
which to use when.

Thanks to Davyd Madeley for extensive debugging assistance, and credit to
Manish Singh, James Henstridge, and Malcolm Tredinnick for having analyzed the
root cause issue and having clarified that two code paths would indeed be
necessary.

As often happens when you kick a stone loose, we were able to do a number of
refactorings to clean things up. This eventually led to the realization (ok,
epiphany) that our treatment of the GValue mechanism was needlessly complex.
Toss. We no longer have individual Value subclasses for each different
fundamental type, but rather just leave them as opaque references:

 * <span style="text-decoration: line-through;">
   `org.gnome.glib.Fundamental`
 * <span style="text-decoration: line-through;">
   `org.gnome.glib.StringValue`  
 * <span style="text-decoration: line-through;">
   `org.gnome.glib.BooleanValue`
 * <span style="text-decoration: line-through;">
   `org.gnome.glib.IntegerValue`
 * <span style="text-decoration: line-through;">
   `org.gnome.glib.EnumValue`
 * <span style="text-decoration: line-through;">
   `org.gnome.glib.ObjectValue`
 * **`org.gnome.glib.Value`**
 * `org.gnome.glib.Plumbing`

This allowed a further simplification of the `valueFor()` mechanism and even
more smashing about in Plumbing with a chainsaw. Net result was a _reduction_
by several hundred lines of code. Yeay!

All of these changes were confined to the internals of the binding machinery
and are not user visible.

Loading `.glade` files
----------------------

User interface designers are nothing new, but one of the really cool things
about GTK has long been the existence of `libglade`. It's a library which
takes the output of a one of the GNOME user interface designers (such as such
as **Glade 3** or **Gazpacho**) and dynamically, at runtime, generates live
Windows full of Widgets!

With the arbitrary Proxy retrieval sorted out, the beginnings of a binding of
`libglade` was possible. None of the fancy stuff is there yet, but a `.glade`
file can be loaded, and Widgets retrieved from the instantiated tree.

* **`org.gnome.glade.Glade`**
* **`org.gnome.glade.Xml`**
* _`org.gnome.glade.GladeXml`_

The JavaDoc for these classes clearly indicates that this is preliminary and
subject to change. It may well all be blown away when GtkBuilder lands. We'll
see.

Testing framework
-----------------

We've introduced the beginnings of a unit test framework. At the moment, this
just evaluates various getters and setters without doing anything that
requires the main loop. Despite this, the unit tests end up exercising the
entire Proxy system discussed above; validating that the properties set and
get and that the correct Proxy object is returned through a round trip is no
mean feat.

You can run the suite from Eclipse, by specifying a JUnit 3 launcher on class
UnitTests in the default package in `tests/java`, or by running 

	$ make test

from the command line.

Further coverage
----------------

This release also sees the addition of:

* **`org.gnome.gtk.FileChooser`**
* **`org.gnome.gtk.FileChooserAction`**
* **`org.gnome.gtk.FileChooserButton`**

Along with mocked up code for:

* _`org.gnome.gtk.GtkFileChooser`_
* _`org.gnome.gtk.GtkFileChooserAction`_
* _`org.gnome.gtk.GtkFileChooserButton`_

This is significant because GtkFileChooser is an _interface_ in GTK, and
GtkFileChooserButton implements it. We'd been putting off the question of
dealing with GInterface (would it work or be a major problem?) for a while
now. We were delighted to find that the design implied by the re-engineered
bindings handled it cleanly, elegantly, and without any fuss. Another nice
validation of our new architecture.

Finally, a number of new signals were exposed on: 

* **`org.gnome.gtk.Widget`**

though these were mostly the result of doing live demonstrations at
conferences of how easy extending the coverage of the new bindings is.

Memory management
-----------------

We have successfully implemented full GObject memory management in java-gnome
4.0 using GLib's ToggleRef mechanism.

A strongly referenced Java Proxy will not allow its GObject to be destroyed
out from underneath it; meanwhile, as long as the GObject is still referenced
by something other than java-gnome, an otherwise only weakly reachable Java
object that Proxies it will not be finalized. When the situation _does_ occur
whereby the GObject is only referenced from java-gnome, and the Java object is
no longer strongly referenced by any other Java objects, then the Java object
can be garbage collected and the GObject will be unref()'d and destroyed.

You can watch the reference system in action if you set
`Debug.MEMORY_MANAGEMENT` to `true`.

Huge thanks go to Vreixo Formoso Lopes who collaborated on the design,
reviewed the implementation, and contributed test case code.

Build system improvements
-------------------------

A better detection of jni.h is done on Ubuntu, thanks to Michael Kedzierski.
This makes java-gnome more likely to build out of the box on Debian-derived
systems.

On the eve of release, Srichand Pendyala noticed that if you are running such
a system, a package named `libglade-dev` needs to be installed. Of course, on
more modern systems all the necessary dependencies are present merely by
having GNOME installed in the first place. We'll add a check for this Debian
specific behaviour in 4.0.3.

The `VERSION` and `APIVERSION` constants were moved to

* `org.gnome.gtk.Version`

so that anyone working on the Gtk main class isn't forced to do a
re-configuration every time they save.

Installation and Packaging
--------------------------

java-gnome 4.0 now has the standard `make install` command, and the equally
standard `--prefix` option to `./configure`.

	$ ./configure --prefix=/usr
	$ make
	$ sudo make install

The `install` target understands the `DESTDIR` variable used by packagers to
install to a specified prefix _within_ a temporary directory.

See the [`README`](README.html) file for details.

Looking ahead
-------------

The feature additions described above were done to bring java-gnome up to
speed for the GTK & GNOME tutorial given at [linux.conf.au][LCA]. With that
past, we're not going to do any more manual mockups of code in what will be
the generated layers. Focus now turns to designing and implementing the tool
that will parse `.defs` files and output the translation code.

Once we secure funding for the project, the code generator will be our top
priority and shouldn't take more than a couple months to complete.

AfC

[LCA]: http://lca2007.linux.org.au/talk/258


<a name="4.0.1" id="1167969613" title="Prototype becomes foundation"></a>

java-gnome 4.0.1 (05 Jan 2007)
==============================

_It's not really a prototype anymore! the design works, and so the code that
is here is forming the foundation of the new Java bindings for GTK and GNOME._

While there are some significant pieces of engineering that are yet to be
done, and of course a universe of coverage yet to write, we're pleased to mark
the milestone of the prototype having proved itself to be stable and the
strong foundation that we need. In this release:

Project documentation
---------------------

Import project documentation, initially consisting of the re-engineering
emails written by Andrew Cowie to the java-gnome-hackers mailing list, and
expanded to include top level [`README`](README.html) and
[`HACKING`](HACKING.html) files, and a style guide for contributors to follow.
All documentation [re]formatted in Markdown syntax so as to be renderable to
web pages. See [`doc/design/`](doc/design/START.html) and
[`doc/style/`](doc/style/).

Project website
---------------

Create an entirely new website for <http://java-gnome.sourceforge.net/>,
introducing sections "[About](/4.0/)", "[Documentation](/4.0/doc/)",
"[Download](/4.0/get/)" and "[Interact](/4.0/lists/)" to discuss the the
project as a whole, to be a home for the documentation, to provide
instructions on how to get java-gnome, and information about the mailing lists
and IRC channel, respectively. Also include a page thanking the previous
generations of maintainers for their hard work and noting that the
[2.x](/2.x/) bindings have been unmaintained for some time now and are
formally deprecated.

The website is no longer a wiki but is entirely within the source code of
java-gnome itself. See the `web/public/` directory; improvements welcome.

Major engineering
-----------------

Quite significantly, the infrastructure to get a Proxy or Constant instance
for any arbitrary C side pointer or enum is complete, involving _significant_
work to:

 * `org.freedestkop.bindings.Plumbing`
 * **`org.freedestkop.bindings.Proxy`**
 * **`org.freedestkop.bindings.Constant`**
 * `org.gnome.glib.Plumbing`
 * **`org.gnome.glib.Value`**
 * `org.gnome.glib.GValue`
 * `org.gnome.glib.Fundamental`
 * **`org.gnome.glib.Object`**

Along with the corresponding C side code, especially in `GValue.c`

This was a necessary building block in order to complete the generalized
`getProperty()` mechanism that, while hidden from public view, is nevertheless
a major aspect of the GObject tool chest and is usable by bindings hackers
when necessary. The generalized instance mechanism was the last major
engineering hurdle that needed to be achieved in order to prove the new
bindings design.

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

* **`org.gnome.gtk.Label`**
* **`org.gnome.gtk.Fixed`**
* **`org.gnome.gtk.Box`**
* **`org.gnome.gtk.VBox`**
* **`org.gnome.gtk.HBox`**

Along with

* _`org.gnome.gtk.GtkLabel`_
* _`org.gnome.gtk.GtkFixed`_
* _`org.gnome.gtk.GtkBox`_
* _`org.gnome.gtk.GtkVBox`_
* _`org.gnome.gtk.GtkHBox`_

And corresponding [working] mockup native code.

Compliments to Srichand Pendyala from Bangalore, India for being the first
external hacker to have a patch accepted to mainline! He contributed methods
to Label and initiated the implementation of the Fixed class. In so doing, he
also helped work the bugs out of the `bzr bundle` submission process. Awesome.

Build improvements
------------------

java-gnome now builds on Ubuntu and OpenSolaris in addition to its home turf
of Gentoo. Thanks to John Rice of Sun Microsystems who provided the guidance
allowing us to port Equivalence to Solaris some months ago, and Laszlo Peter,
also of Sun Ireland, for several fixes to allow configure to recognize a wider
range of Solaris environments.

The tiny example program that we have been using to validate the code,
`Experiment` is now compiled by the build system if you so request. Try `make
demo`.

API documentation
-----------------

Extensive attention has been paid to the JavaDoc for the few methods that are
presented so as to clearly set the standard required. The canonical JavaDoc
for the project is available at the website with a stable URL and can be
linked to.

All source code [comments, ie JavaDoc] have been spell checked! Initial top
level `overview.html` and `package.html` files have also been written to help
round out the JavaDoc.

AfC


<a name="4.0.0" id="1164533400" title="First public demonstration"></a>

java-gnome 4.0.0 (26 Nov 2006)
==============================
 
_Initial release of the java-gnome 4.0 prototype, corresponding to the first
public demonstration of the new bindings done at
[foss.in/2006](http://foss.in/2006/) at Bangalore, India._

The prototype is fully functional and is intended to prove the design and
architecture we have arrived at as a result of the re-engineering process. It
includes both real wrapper layer classes that are the seed from which our
public API will grow, along with the infrastructure that the wrapper layer
depends on.

Initial coverage
----------------

Wrapper layer presenting the public API to developers (publicly visible
classes in bold):

* **`org.freedesktop.bindings.Proxy`**
* **`org.gnome.glib.Value`**
* **`org.gnome.glib.Object`**
* **`org.gnome.gtk.Object`**
* **`org.gnome.gtk.Widget`**
* **`org.gnome.gtk.Container`**
* **`org.gnome.gtk.Bin`**
* **`org.gnome.gtk.Button`**
* **`org.gnome.gtk.Window`**

Along with complete translation layer implementations for each:

* `org.freedesktop.bindings.Plumbing`
* `org.gnome.glib.Plumbing`
* `org.gnome.glib.GValue`
* `org.gnome.glib.GObject`
* `org.gnome.gtk.GtkObject`
* _`org.gnome.gtk.GtkWidget`_
* _`org.gnome.gtk.GtkContainer`_
* _`org.gnome.gtk.GtkBin`_
* _`org.gnome.gtk.GtkButton`_
* _`org.gnome.gtk.GtkWindow`_

At present the bindings mock up the code that will be generated with
temporarily hand written substitutes (ie, those in italics above) for both
translation (Java) and native (C) layers. These will do until we receive the
funding to make the code generator a reality; we certainly don't want to be
writing much more translation layer Java and C code by hand. Yuk.


Signal API
----------

The defining aspect of GUI programming is, of course, that it is event driven.
In addition to the "forward" direction of making calls to the native library
and having return values bubble back up, there is the "reverse" direction of
connecting callback handlers to the various signals that different Widgets
offer, and having those signal events result in those handlers being invoked.

java-gnome 4.0 has an entirely new and redesigned signal connection and
callback API. This functionality was demonstrated, and coverage of
**`Button.CLICKED`** and **`Window.DELETE`** is now present and functional!
The APIs used by GNOME language bindings to achieve this are some of the most
voodoo I have ever seen. But it's hooked up, and it works. It's like black
magic :)

Build
-----

java-gnome is configured and built using Andrew Cowie's Equivalence build
scripts. It builds on Gentoo and should build on a Debian or Fedora derived
system as well. See [`README`](README.html) for further details.

At the moment, java-gnome is a single source package.

The source code is available via `bzr`. Again, see `README`.

AfC

<!--

  Copyright (c) 2007 Operational Dynamics Consulting Pty Ltd 

  As project documentation, this file forms an integral part of the source
  code of the library it accompanies, and thus is made available to you by the
  authors under the terms of the "GNU General Public Licence, version 2". See
  the LICENCE file for the terms governing usage, copying and redistribution.

  vim: set textwidth=78 nowrap:

-->
