java-gnome-hackers — Hacking on the bindings themselves: design issues and co-ordination

[java-gnome-hackers] Pushed to 1.5

[Andrew C. <an...@op...>]

At Vreixo's request, I've just merged the 'generics' branch to
'mainline'. This completes the migration (that was announced as taking
effect after the 4.0.3 release) to Java 1.5 being the minimum required
language version to build and work with java-gnome.

Big job. There was a lot of work that needed doing to infer generics
arguments everywhere and get rid of (most of) the warnings.

As you'd expect, people who have pulled to or beyond revno 457 will need
to reconfigure and rebuild. So,

$ ./configure
$ make clean
$ make test

AfC
Toronto

-- 
Andrew Frederick Cowie

Operational Dynamics is an operations and engineering consultancy
focusing on IT strategy, organizational architecture, systems
review, and effective procedures for change management. We actively
carry out research and development in these areas on behalf of our
clients, and enable successful use of open source in their mission
critical enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

Re: [java-gnome-hackers] Mixing generated and hand-written classes

[Colin W. <wa...@ve...>]

One other note - I just looked at the gtk-sharp code base, and like
PyGTK they use the approach of merging generated and hand-written code
as well.

Here's an example:
http://anonsvn.mono-project.com/source/trunk/gtk-sharp/gtk/TextView.custom

Both PyGTK and Gtk# are very successful bindings, and I would argue
that this success derives very much from *completeness*.  There's no
reason the java-gnome bindings can't do just as well.  We have most of
the pieces.

[java-gnome-hackers] Analyzing the hand-written binding growth over time

[Colin W. <wa...@ve...>]

My hypothesis is that the current system of hand-writing all bindings
is not sustainable, unless there were a dramatic influx of new
committers to this project.  And even then, we would still have
long-term issues with API consistency.

Attached is a Python script which generates statistics that I believe
support this hypothesis.

The basic idea is to count the coverage per unit of time.  I chose to
use a week.   Here's sample output from my script:

offset: -0 revnum: 455 methods: 1010
offset: -1 revnum: 453 methods: 1010
offset: -3 revnum: 450 methods: 1010
offset: -5 revnum: 444 methods: 990
offset: -6 revnum: 433 methods: 974
offset: -7 revnum: 429 methods: 970
offset: -8 revnum: 421 methods: 935
offset: -9 revnum: 410 methods: 914
offset: -10 revnum: 404 methods: 861
offset: -14 revnum: 403 methods: 861
offset: -15 revnum: 399 methods: 860
offset: -16 revnum: 395 methods: 691
offset: -17 revnum: 371 methods: 663
offset: -18 revnum: 355 methods: 558
offset: -19 revnum: 352 methods: 513
offset: -21 revnum: 351 methods: 512

The "offset" is the number of weeks ago, "revnum" corresponds to the
BZR revision number from mainline, and "methods" is the number of
implemented methods, as adapted from src/utils/coverage.pl.

We can see in this graph that progress has been pretty jumpy; in the
last few weeks the coverage has not increased at all.  I don't have
the precise number handy, but from an observation it looks like the
project is perhaps adding 30 methods/week, tops.  According to the
hardcoded number in coverage.pl, there are 5468 methods to implement,
and currently we have 1010.

Using that conservatively-high rate of 30 methods/week, hand-writing
4358 bindings will take 145 weeks.  That's 2.7 *years*.  But even that
is probably overly optimistic, because some parts of the API are much
harder to bind than others.

I've attached the full output from my script, as well as the script
itself.  You can regenerate the results like this:

python coverage-revisions.py /path/to/java-gnome

Re: [java-gnome-hackers] Mixing generated and hand-written classes

[Colin W. <wa...@ve...>]

On Fri, Mar 21, 2008 at 11:58 AM, Vreixo Formoso Lopes
<met...@ya...> wrote:
> [...] where things are done
>  in the way a Java developer expects them,

This goal doesn't help me, a "platform hacker".

 and with a
>  good documentation.

Again, certainly nice but I can do OK since the C API is documented,
and as long as you have a decent algorithmic mapping, it's pretty easy
to understand what the API will be like to use from Java.

> Seriously, I doubt the Gtk+
>  documentation is good for Java bindings. (well, in
>  fact I do not doubt, I'm sure it isn't!).

Using the GTK+ docs has worked out quite well for PyGTK+.

>  I understand that for apps developers it is a pain to
>  wait for the coverage they need. But I really prefer
>  good bindings tomorrow than bad bindings today. And if
>  you really need coverage for a given widget, just
>  request us to implement it!!

Ok, I am in the process of writing a script to prove that the current
system is not sustainable.  I'll post it soon.

Re: [java-gnome-hackers] Mixing generated and hand-written classes

[Andrew C. <an...@op...>]

On Fri, 2008-03-21 at 12:58 -0300, Vreixo Formoso Lopes wrote:
> But I really prefer
> good bindings tomorrow than bad bindings today.

/me cheers!

:)

AfC
Toronto

Re: [java-gnome-hackers] Mixing generated and hand-written classes

[Vreixo F. L. <met...@ya...>]

--- Colin Walters <wa...@ve...> escreveu:

> I don't think something like this would be too hard
to achieve with
> the current code generator 

In fact, it is quite easy! Having a direct mapping
from Gtk+ to Java is very easy with current code
generator, but that way what we would be doing is
using in Java an API designed for C!! Do we really
want that? Or we prefer a quality API carefully
designed for the Java language? 

With the first option we would have in less than a
week bindings for all Gtk+ functions. But would they
be a good bindings? I doubt. Only humans, by carefully
testing and exploring each of the Gtk+ functions can
provide quality Java bindings, both powerful but
easy-to-use and easy-to-learn, where things are done
in the way a Java developer expects them, and with a
good documentation. Seriously, I doubt the Gtk+
documentation is good for Java bindings. (well, in
fact I do not doubt, I'm sure it isn't!).

Of course, having to hand-coded all our API is much
more work, but that is the price we pay for having
good bindings. Each hour we waste handcoding good API
and docs, is time hundreds of developers won't need to
waste learning an ugly, bad documented API.

We are not developing an end-user app, but a library
many developers will use for writing their apps. Let's
do it ok. 

You may ask, then: why to worry about a code
generator? Because this way the ugly and tedious part
(the direct mapping, JNI layer, etc) is done
automatically!! So we expend our time studying Gtk+
functions and the way they should be mapping in Java,
and not writing JNI code!! In fact, thanks to the code
generator, I waste less than 1% of my java-gnome work
writing code. That is good.

I understand that for apps developers it is a pain to
wait for the coverage they need. But I really prefer
good bindings tomorrow than bad bindings today. And if
you really need coverage for a given widget, just
request us to implement it!! And contribute, of
course! If you use a widget sure you will have good
ideas about how it should be implmented in Java!

Cheers,
Vreixo





      Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento!
http://br.mail.yahoo.com/

Re: [java-gnome-hackers] Mixing generated and hand-written classes

[Colin W. <wa...@ve...>]

On Fri, Mar 21, 2008 at 10:52 AM, Andrew Cowie
<an...@op...> wrote:
> On Fri, 2008-03-21 at 01:52 -0400, Colin Walters wrote:
>  > What would happen at the build process is that we'd parse that Java
>  > file,
>
>  Trying to inject hand written code into generated code is the defining
>  nightmare that the Enterprise Java world saddled itself with, to their
>  sorrow. We've spent two years steering clear of it; indeed the entire
>  architecture was designed with avoiding that anti-pattern in mind.

What are the concrete issues you see?  The slide link doesn't say.
And I don't see how this approach is related to "Enterprise Java".
What are you talking about?  EJB2?

> Human written JavaDoc is not an option; it is the *entire* point.

Simply put, I think it is more important to have as much coverage as
possible, with a completely consistent and predictable mapping.  After
that base is achieved, then you can go back and add custom
documentation at any time.

Now admittedly, I come from the C GTK+ world originally, and I've been
hacking on the platform for probably 7 years now.  So my perspective
is biased towards that world; though in the last 2-3 years I've been
immersed in the Java world.  What is bad about the hand-coding
approach for me is that it's *impossible* for me to write a nontrivial
application in Java/GNOME as is.

For targeting people who are coming entirely from the Java world and
are new to the platform, nice JavaDoc is certainly going to help.  But
look at it this way, the current approach of hand-coding bindings is
still broken for them, because although they get a nicer subset of the
API, they're still going to run up against coverage and consistency
issues.

I'm really worried that this project is going back into completely
hand-coded, custom mode.  Here's an example I found from the archives:
http://article.gmane.org/gmane.comp.gnome.bindings.java.devel/1018
There is no metadata in the .defs file telling you that that's a
method which emits a signal.  So how would you do something like that?
 In the current architecture, you'd hand-code it into the class.  But
then what happens a year from now, when someone adds a new method in
GIO like that, and some Java-GNOME contributor forgets about this rule
and binds it without the "fire" prefix or whatever?  The system
becomes inconsistent and confusing to both "platform hackers" and
"Java people" alike.

> The C API documentation discusses C memory management issues which are meaningless to a Java developer using our library.

Most of the methods that discuss memory management are of the form
foo_free or the like, which we aren't going to be binding at all.
I'm taking a closer look at the PyGTK system now to figure out how
their documentation system works.

Re: [java-gnome-hackers] Mixing generated and hand-written classes

[Andrew C. <an...@op...>]

On Fri, 2008-03-21 at 01:52 -0400, Colin Walters wrote:
> What would happen at the build process is that we'd parse that Java
> file,

Trying to inject hand written code into generated code is the defining
nightmare that the Enterprise Java world saddled itself with, to their
sorrow. We've spent two years steering clear of it; indeed the entire
architecture was designed with avoiding that anti-pattern in mind.

In any event, the outer edge hand written bindings layer has turned out
to be useful in all sorts of ways. Not the least of which is keeping
control of the public API being presented.

But most of all, that the translation, native, and JNI layers are
generated is simply automating the output of the cumbersome machinery
necessary to get from Java to C. The poor bastards who wrote the 2.x
version of java-gnome did *all* that by hand; we've simply taken the
drudgery part where cut and paste errors are made and streamlined it.

The API presented to humans by java-gnome 4.0 is lovingly crafted by
other humans, which is as it should be.
http://www.operationaldynamics.com/reference/talks/PastPresentFuture/img75.html

> The javadoc appears to be handcoded
> to be nicer, but again I think the approach of generating from gtk-doc
> is the right thing to do,

No. The structure of java-gnome is not a consequence of nice to haves,
it is a consequence of the objectives and design constraints. Human
written JavaDoc is not an option; it is the *entire* point.

The C API documentation discusses C memory management issues which are
meaningless to a Java developer using our library. They refer to
deprecated and obsolete functions and methods, mentions which would be
impossible to strip out in a systematic. But worst of all, that
documentation is reference style, and notorious for being extremely
difficult to learn from. We have adopted the tutorial style for our
documentation, and that's not a 1:1 transform. See
http://java-gnome.sourceforge.net/4.0/doc/design/2b-DesignConstraints.html

++

If you missed them, you might have a reread of
http://java-gnome.sourceforge.net/4.0/objectives.php 
Perhaps also look at
http://www.operationaldynamics.com/reference/talks/PastPresentFuture/img65.html if you weren't at my talk at GUADEC. I suppose I should apologize that I haven't updated any of the doc/design/ material in a long while now; it was all written before we initiated the rewrite and in the early days  as I had a working prototype in place. Looking back over two years' work, though, I'm pretty pleased that we're still holding closely to our aims, and I'm happy with where things stand now.

Ultimately, my mission here is to open up GNOME to an entirely new group
of contributors who have not previously been participants in the Open
Source movement. That's a different optimization than doing things the
way the existing GTK C developers might have done it. That said, it was
pretty nice to get so much support last summer at GUADEC and at Boston
Summit, and last week from the GTK hackers in Berlin. I make a point of
highlighting behaviours that might have been unexpected, and their
support has generally been overwhelming.

One of the great things about the GNOME community over the last three
years has been people's willingness to tolerate our work and to go
through our designs and give us feedback. So I appreciate your notes.

AfC
Toronto

-- 
Andrew Frederick Cowie

Operational Dynamics is an operations and engineering consultancy
focusing on IT strategy, organizational architecture, systems
review, and effective procedures for change management. We actively
carry out research and development in these areas on behalf of our
clients, and enable successful use of open source in their mission
critical enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

[java-gnome-hackers] Mixing generated and hand-written classes

[Colin W. <wa...@ve...>]

Hi, I just today tried to use java-gnome for the first time, and ran
into the issue of the TextBuffer/TextView not being bound.

What I didn't understand at first was why that blocked me from
instantiating a TextView at all - if we're generating code as I'd
heard java-gnome 4.x is, then certainly I'd have access at least to
the constructor?

Now, I just read through
http://java-gnome.sourceforge.net/4.0/doc/design/5a-Architecture.html
and I understand what's going on.  I think the design has a lot of
good ideas, but the crucial bit that strikes me as wrong is this:

"2. inheritance hierarchies — who is extending what? Given that any
native G entity has two parts on the Java side (the hand written part
with the API that we expose, and the machinery that we generate..."

If you look at PyGTK, their approach is to have *one* class, with
hand-written "overrides".  The huge advantage of this approach is it
means that you automatically get access to *almost* everything - it
may not be as *nice* as you'd like, but it's there.  The current
java-gnome approach seems to me it is still much like writing manual
bindings, just the generated layer is nicer than JNI.

Going back to the "Great Owen Thread" from 2005, he said this:

"Well, I wouldn't characterize that as my core objection ... my core
 objection is really the lack of a consistent and predictable mapping
 between the GObject signature of an object and the Java signature."

The way I think of this is that completeness and correctness are more
important than being the slickest Java API.  The problem is that as
soon as you deviate at all from autogeneration, it is an ongoing
maintenance and documentation burden.  This is another point about
PyGTK - they automatically generate their documentation from the
existing gtk-doc.

Here is a concrete goal - when someone adds a method to the GTK
platform, say in the new GIO work, there is 0 work required in
java-gnome to expose that method, including the gtk-doc documentation
from it.

What this means is that I think we need an architecture, like what
PyGTK has, for generating a *single* class from two sources:

1) Autogenerated code from .defs file, possibly filtered
2) Hand-written overrides

There's a number of ways to do this.  Let's take a quick look at a
sample PyGTK override:

override gtk_text_view_buffer_to_window_coords kwargs
static PyObject *
_wrap_gtk_text_view_buffer_to_window_coords(PyGObject *self, PyObject *args,
                                            PyObject *kwargs)
{
    static char *kwlist[] = { "win", "buffer_x", "buffer_y", NULL };
    GtkTextWindowType win;
    gint buffer_x, buffer_y, window_x = 0, window_y = 0;
    PyObject *py_win;

    if (!PyArg_ParseTupleAndKeywords(args, kwargs,
                                     "Oii:GtkTextView.buffer_to_window_coords",
                                     kwlist, &py_win, &buffer_x, &buffer_y))
        return NULL;
    if (pyg_enum_get_value(GTK_TYPE_TEXT_WINDOW_TYPE, py_win, (gint *)&win))
        return NULL;
    gtk_text_view_buffer_to_window_coords(GTK_TEXT_VIEW(self->obj), win,
                                          buffer_x, buffer_y,
                                          &window_x, &window_y);
    return Py_BuildValue("(ii)", window_x, window_y);
}

Imagine that we defined an overrides file like this:

public class GtkTextView {
  public int[] bufferToWindowCoords(int x, int y) {
     int[] retval = new int[2];
     int[] windowX;
     int[] windowY;
     gtk_text_view_buffer_to_window_coords(pointerOf(self),
numOf(win), bufferX, bufferY, windowX, windowY);
     retval[0] = windowX[0];
     retval[1] = windowY[1];
     return retval;
  }
}

What would happen at the build process is that we'd parse that Java
file, detect a method named bufferToWindowCoords which maps to
gtk_text_view_buffer_to_window_coords, and remove the autogenerated
method.  Instead of parsing Java code, we could have a magic comment
like
// generator override gtk_text_view_buffer_to_window_coords

I don't think something like this would be too hard to achieve with
the current code generator - if we tweak the class name to match the
formerly hand coded version, remove the explicit "self" passing (I
don't understand why that's there?), then we could start to merge in
the existing hand-coded classes with generated ones, and keep what
parts of the hand-coded things that are nicer.

Taking a concrete example here - the hand-coded GtkAboutDialog.java
API is basically identical to the generated GtkAboutDialog, except for
the static method transformation.  The javadoc appears to be handcoded
to be nicer, but again I think the approach of generating from gtk-doc
is the right thing to do, except for explicit overrides.

What do you think?

[java-gnome-hackers] i18n in java-gnome

[Vreixo F. L. <met...@ya...>]

Hi!

Today I have been working in providing an i18n
infraestructure to java-gnome. At this time the
results are really promising. I hope to publish my
branch as soon I have it documented, but here are a
few comments:

* Message resource format / translation function. The
alternatives are

  1. Java way, ie. .properties files for translated
messages, ResourceBundle for translation. 
     Problems: i18n not integrated into GNOME system,
the usage of message keys in the code is ugly and
tedious, plain english messages (as gettext does) is a
much better alternative.
  2. GNU gettext way for java. PO files get "compiled"
in .properties files. ResourceBundle for translation,
but usage of english messages instead of keys. It need
the gettext java library.
  3. GNU gettext way for C. PO files that are
"compiled" to .mo files, stored usually under
/usr/share/locale/ It is what most Gnome apps use, the
needed C library is installed as part of the Gnome
enviromment, and we only need JNI wrappers for it.

I think both (2) and (3) are good alternatives. (2) is
easy to use, because apps just need to store the
.properties on the classpath, while (3) needs to take
care of the place where app is installed (usually this
is done by the build system). 

I have chosen for 3) because its better integration
with GNOME enviroment. Anyway, offering support for
(2) as an alternative may be a good idea. In any case,
we must offer a clean interface. I've created a
org.gnome.glib.I18n class with a static method

public static String _(String msg);

together with Java 5 static imports, a Java program
would look much like a C program. Good.

Now comes the initialization part. In C, the app must
call a setof functions to intilize the app domain and
provide the location of the compile PO files. I've
encapsulated all this ops in a I18n static function:

public static void init(String packageName, String
localeDir);

Ok, this is enought. If an app wants to use
internacionalization, it must call that function, with
the domain name (usually the application name) and the
location of compiled PO files. I wonder, however,
whether we could use another alternative. My proposal
is that when user call Gtk.init(), we try to locate an
i18n.properties file on classpath, from where to read
both values. If the file can't be found, the _()
function just returns the original message, i.e. we
skip internacionalization. In fact, we can even use a
java-gnome.properties, as it might be needed for some
other purposes in a future.

* Message formating

I18n does not only refer to message translation, there
are other important things, such as the format for
numbers, dates, etc. gettext() has no support for
this, as C has lots of functions related to that.
However, in Java we have the cool MessageFormat, that
supports locale dependent formatting. I have chosen,
thus, to combine the power of gettext translation with
the power of MessageFormat formating, thus leading to
a function:

public static String _(String msg, java.lang.Object
...parameters) {
	if (msg == null) {
	    return null;
	}
	if (!initialized) {
	    return MessageFormat.format(msg, parameters);
	} else {
	    return MessageFormat.format(gettext(msg),
parameters);
	}
}

where the message is formatted after being translated.
The results are really good.

---


The main problem just now is the need to write some
scripts to automatize the PO managing, as existent
tools are based on autotools. I hope to take a look at
it soon.

Cheers,
Vreixo


      Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento!
http://br.mail.yahoo.com/

Re: [java-gnome-hackers] More thougths about TreeView and related

[Andrew C. <an...@op...>]

On Sun, 2008-03-16 at 18:27 -0300, Vreixo Formoso Lopes wrote:
> === modified file 'src/bindings/org/gnome/gtk/TreeIter.java'
> --- src/bindings/org/gnome/gtk/TreeIter.java    2008-01-14 03:53:07
> +0000
> +++ src/bindings/org/gnome/gtk/TreeIter.java    2008-03-15 19:18:49
> +0000
...

> +    public boolean hasChild() {
...
> +    public TreeIter children() {
...
> +    public TreeIter children() {
...

Unfortunately TreeIters are not stable first class references.

I'll wait to so see what Srichand thinks of this, but I really don't
think we should put this stuff on TreeIter. We moved one method only to
TreeIter and that was just to make cycling over a model work.*

The three methods you are proposing to add above are specialities of
TreeStore and really do belong there (actually, they are part of the
TreeModel interface, so the open question is whether you ever need the
hierarchy methods on a model that is not a TreeStore), and not on
TreeIter.

[* and even that's sketchy: I am hitting a bug this week where a
TreeModel is failing to update because I am making changes to something
which affects the sort order while looping over a model's data. I should
know better]

AfC
Toronto

Re: [java-gnome-hackers] New coverage: Expander, SpinButton and RadioButton,

[Vreixo F. L. <met...@ya...>]

--- Andrew Cowie <an...@op...>
escreveu:

> On Tue, 2008-03-18 at 13:41 -0300, Vreixo Formoso
> Lopes wrote:
> > RadioButton
> 
> Did you talk to Mario at all before doing this? He
> was also working on
> it.

ups, sorry, I didn't know.

> The GTK hackers pointed out to us that the notion of
> "group" as an
> argument to the RadioButton constructors was
> entirely C sugar and not
> necessarily GTK API.

I haven't exposed the group concept, only a function
to get all RadioButtons that were in a group. Be free
to make it private!

> I'd like to see what sort of API we can come up with
> that doesn't
> require using the first RadioButton as an argument
> to all the others.

I think that is the better alternative. Otherwise we
need to create some kind of RadioButtonGroup object. I
think my approach is better. I will try to find Mario
on IRC tonight, anyway.

Cheers,
Vreixo



      Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento!
http://br.mail.yahoo.com/

Re: [java-gnome-hackers] New coverage: Expander, SpinButton and RadioButton,

[Andrew C. <an...@op...>]

On Tue, 2008-03-18 at 13:41 -0300, Vreixo Formoso Lopes wrote:
> RadioButton

Did you talk to Mario at all before doing this? He was also working on
it.

The GTK hackers pointed out to us that the notion of "group" as an
argument to the RadioButton constructors was entirely C sugar and not
necessarily GTK API.

While I haven't looked at this closely yet, Mario and I did discuss that
the translation of that C sugar into java-gnome worked out to be pretty
ugly to use.

I'd like to see what sort of API we can come up with that doesn't
require using the first RadioButton as an argument to all the others.

AfC
Toronto

[java-gnome-hackers] New coverage: Expander, SpinButton and RadioButton,

[Vreixo F. L. <met...@ya...>]

Hi!

I have added some new coverage: Expander, SpinButton
and RadioButton, take a look at attached patch. The
first ones are quite straightforward, RadioButton is a
another question. Please take a look to code comments
and commit message for details.

Cheers,
Vreixo


      Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento!
http://br.mail.yahoo.com/

Re: [java-gnome-hackers] More thougths about TreeView and related

[Andrew C. <an...@op...>]

On Sun, 2008-03-16 at 18:27 -0300, Vreixo Formoso Lopes wrote:
> 1. I've noticed you have implemented TreeModel as an
> abstract class instead of an interface. In my opinion
> this is a good design decision. However, I don't like
> one things, the dispatch function and its ugly "if
> (this instanceof XXXX)".

Yeah, changing that is fine.

AfC
Paris

-- 
Andrew Frederick Cowie

Operational Dynamics is an operations and engineering consultancy
focusing on IT strategy, organizational architecture, systems
review, and effective procedures for change management. We actively
carry out research and development in these areas on behalf of our
clients, and enable successful use of open source in their mission
critical enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

[java-gnome-hackers] More thougths about TreeView and related

[Vreixo F. L. <met...@ya...>]

Hi!

Some more thoughts about TreeView and related widgets


1. I've noticed you have implemented TreeModel as an
abstract class instead of an interface. In my opinion
this is a good design decission. However, I don't like
one things, the dispatch function and its ugly "if
(this instanceof XXXX)". It would be much better to
have a protected method and let its subclasses
(ListStore, TreeStore...) overwrite it (Object
Oriented way!!). See attached patch.

2. A problem of the TreeModel as abstract class design
is that it allows users to call setValue() on
TreeModels that do not have such method, for example
TreeModelFilter, of course getting the
UnsupportedOperationException. I wonder, however,
whether we could implement dispatch() in such models.
For example, in TreeModelFilter we could delegate the
operations in the base model easily. What do you think
about this?

3. I've noticed TreeSortable interface is still not
implemented. Is it by design, or just missing
coverage? At a first sight, it seems setSortColumn()
in TreeViewColumn is enought to sorting. However, this
do not allow us to sort elements in a ComboBox, for
example. And there is a missing feature: the
gtk_tree_sortable_set_sort_func(), very useful for
handling non-trivial sort in an easy way. For example,
think again on my "nautilus" example. When sorting
files by name, usually folders are show before files.
In the same way, when sorting by size, we want to sort
by the real size (a long) and not by the String size
we need to use to show the size. Both cases are much
easier of implement with a custom sort function. In my
opinion, this should be exposed using
java.util.Comparator<TreeIter> interface, and of
course implemented internally using our signal
handling system. I'd like to implement this, but
please give me you opinions.

4. DataColumnPixbuf has a bug. Its type should be
GDK_TYPE_PIXBUF, and not G_TYPE_OBJECT as it is now.
With current implementation you get a

(java:6304): Gtk-CRITICAL **:
gtk_icon_view_set_pixbuf_column: assertion
`column_type == GDK_TYPE_PIXBUF' failed

when used with a IconView. The solutions is quite
easy, but requires to change Value implemenation. So
here comes the question, where to add the new Value
constructor? Make it sense to add a gdk.Pixbuf
dependence in glib.Value? Should I code it in
gtk.Value instead?

5. GtkCellRendererPixbuf can render a Stock icon via
the stock-id property, that is a gchar array. However,
currently only a Pixbuf can be renderer with our
CellRendererPixbuf. What about adding a new
DataColumnStock? And what we should do? add a
setStock(DataColumnStock) to CellRendererPixbuf, or
either create a new CellRendererStock that obviously
maps to a GtkCellRendererPixbuf? Opinions?

Cheers,
Vreixo



      Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento!
http://br.mail.yahoo.com/

Re: [java-gnome-hackers] Thoughts about TreeStore

[Andrew C. <an...@op...>]

I am subscribed to the java-gnome-hackers mailing list. You don't need
to send messages To me and Cc list. Just send it To the list.

AfC
Berlin

[java-gnome-hackers] Thoughts about TreeStore

[Vreixo F. L. <met...@ya...>]

Hi!

During my work on TreeStore I've faced some problems I
want to discusse with you.

First of all, there is the model field in TreeIter. It
has a problem. Signals like TreeView.ROW_EXPANDED
return a TreeIter, which is instantiated by generic
signal handler that, obviously, do not know how to
initialize the model field. With a simple
implementation, this converts the TreeView parameter
on the signal handled in a completelly useless
parameter. The solution I've taken is add a package
protected setModel to TreeIter, together with removing
of the "final" qualifier in such field. That way, we
can implement a custom signal handler (of course,
private and hidden to the user), that initializes the
missing model field (see attached treestore.patch).
Ok, solved in a quite good way. But a bit ugly, sure.
The model field increments the implementation effort.
Not a problem, actually, if such field really provides
a better API. In my opinion, this is the case. Having
an iterNext() without the need of a model parameter is
sure a good thing. However, given we need extra effort
to have the model parameter in TreeIter, why don't we
take more advantage for each. Of course, I'm
presenting again my old proposal for having the
setValue/getValue function in TreeIter instead of of
TreeModel (see attached itervalues.diff).
This allow to set values of a row without having the
model, and it is useful, for example, to access the
values of a row in a signal handler without needing to
take a reference to the TreeModel. It is already on
TreeIter? Why force users to add extra code to get it?

------

Another question is the way CellRenderers are created.
They always take a CellLayout (ie, a TreeViewColumn)
as a parameter. I'm not against this, but what I don't
like is that they're always added to the given
CellLayout with the expand property set to true. Maybe
I'm missing something (help me!), but it seems it
can't be changed later. If so, this is a design
pitfall. Reason? Think about the left panel of an app
like nautilus (the tree of directories). It is a
TreeView with a single TreeViewColumn, with two
CellRenderers, one for the icon, one for the directory
name. If we set the expand property of the icon to
true (as it seems forced by java-gnome), when the
TreeView gets expanded it appear an ugly white space
between the icon and the dir name. This is ugly. How
can I handle this properly? Is it possible with
current design? If not, we should change this, maybe
with an alternate constructor that takes an additional
"boolean expand" parameter.

Cheers,
Vreixo



      Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento!
http://br.mail.yahoo.com/

Re: [java-gnome-hackers] gtk 1.12 update

[Vreixo F. L. <met...@ya...>]

--- Andrew Cowie <an...@op...>
escreveu:

> Here's a hint: if the program was not called
> ExampleTooltip it would be
> a step in the right direction.

I know... it was planned as a demo to test tooltips
are working, not as an example. I will improve it.

> 
> - It is 2008.

?!?!

> - You have removed Tooltips and added Tooltip, but
> there is no
> documentation in the Tooltip class. 

No, I haven't exposed Tooltip yet. It is not needed to
support tooltips (see methods in Widget), so I think
we can live without it for now, there're many
interesting Widgets not documented yet. Imho, Tooltip
is far for important, when compared with many others.

Cheers,
Vreixo


      Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento!
http://br.mail.yahoo.com/

Re: [java-gnome-hackers] gtk 1.12 update

[Andrew C. <an...@op...>]

On Tue, 2008-03-11 at 06:17 -0300, Vreixo Formoso Lopes wrote:
> Please evaluate attached patch 

- It is nice that you added an example. It would be preferable if we
could work out an example that is something more than trivial, and to
which adding a Tooltip makes the difference between a difficult UI and a
discoverable one.

I'm not sure exactly what that should be; perhaps a Window with two
identical sides, but only one side has tooltips? Or better yet a Window
that is a data entry form (dialog) where there is a large amount of
supporting information in the tooltips explaining how to use it.

Here's a hint: if the program was not called ExampleTooltip it would be
a step in the right direction.

- It is 2008.

- You have removed Tooltips and added Tooltip, but there is no
documentation in the Tooltip class. That won't fly. See Signal for an
example of a class which doesn't have any public methods which is,
nevertheless, clearly documented.

Other than these small points, it's fine so far.

AfC
Berlin

[java-gnome-hackers] gtk 1.12 update

[Vreixo F. L. <met...@ya...>]

Hi!

Please evaluate attached patch instead of what I've
sent last days. It adds many new functions.

Cheers,
Vreixo


      Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento!
http://br.mail.yahoo.com/

Re: [java-gnome-hackers] Fisrt work to update .defs with new 2.12 functions

[Andrew C. <an...@op...>]

On Sat, 2008-03-08 at 13:07 -0300, Vreixo Formoso Lopes wrote:
> Send you a patch with first work on updating .defs to
> Gtk 2.12. I've based my work on pygtk 2.12.1 defs
> data. Some notes:

This is great work Vreixo. Keep it up!

> 4. They have added a flag
> 
> (unblock-threads #t) 
> 
> to some functions that currently are in missing.defs.
> Some I think we don't need to worry about it for now.

Weird. I wonder what they mean by that? Sounds like a pygtk-ism.

> GtkBuilder

Just so everyone knows, GtkBuilder is still a disaster zone. It is *not*
a drop-in replacement for LibGlade yet. In fact, it doesn't even
parse .glade files.

We'll see what progress is made next week in Berlin.

> - Update to Java 5.

I'm about to merge the branch with that, so matter in hand.

>  This opens cool possibilities,
> such as implementation of GtkBuilder based on
> annotations

As I have told you several times already, I'm not yet happy about the
idea behind this. If you use LibGlade there is tight coupling between
program code and a .glade file. Nothing will make that go away.

What was suggested in the feature request I saw didn't address that in
the slightest, and since the proposer didn't answer my questions my lack
of enthusiasm for the idea deepens.

The fact that they did something like that in the .Net bindings of GTK
is neither an argument in favour of, or an argument against, adding this
feature. And saying that Hibernate does something is likewise not a
strong argument in support of something. I'm a db4o guy :)

Anyway, I'm not saying we can never add this, but it needs to be both a)
well thought out and b) a material improvement for us to incur the cost
of supporting it. We can discuss it again at GUADEC.


> Send you a patch 

Like I said, it's awesome you're working on this.

I'll review the branch this week.

AfC
London

-- 
Andrew Frederick Cowie

Operational Dynamics is an operations and engineering consultancy
focusing on IT strategy, organizational architecture, systems
review, and effective procedures for change management. We actively
carry out research and development in these areas on behalf of our
clients, and enable successful use of open source in their mission
critical enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

[java-gnome-hackers] Fisrt work to update .defs with new 2.12 functions

[Vreixo F. L. <met...@ya...>]

Hi!

Send you a patch with first work on updating .defs to
Gtk 2.12. I've based my work on pygtk 2.12.1 defs
data. Some notes:

1. pygtk misses many of new gtk 2.12 functions, I've
added some of them (specially Tooltip related) but we
still need several of them.

2. In several types it has been removed the line

  (return-type "none")

I've reverted such changes.

3. Several

(deprecated)

have been removed. I've instead removed the
definitions from .defs files.

4. They have added a flag

(unblock-threads #t) 

to some functions that currently are in missing.defs.
Some I think we don't need to worry about it for now.

Ok, what I have done:

1. Branch from pygtk
2. Update with current pygtk 2.12.1 defs data. I've
tagged this as "pygtk-2.12" to become a source for
future updates.
3. Merge current mainline. bzr is great!!! It has
handled most of our changes to .defs data
automatically, only a few conflicts appear.
4. Manually add some 2.12 functions that were missing
in pygtk data. I've also updated Tooltips functions
and removed Tooltips class.

Future tasks (I can take care of any of these, waiting
for your comments):

- Continue 2.12 update, i.e., adding all functions
that are still missing (I think they're more than 100
functions!!) Interesting ones may be:
	- New Widgets: GtkScaleButton, GtkVolumeButton
	- New objects (not widgets): GtkRecentAction,
GtkBuilder
- Update to Java 5. This opens cool possibilities,
such as implementation of GtkBuilder based on
annotations (much like object-relational mappers like
Hybernate-annotations)
- Improve memory management. This is a pending task
since several months. We must take care of freeing
returned objects we own (caller-own-return flag in
.defs), specially char* or GList we currently just
convert to string opts without freeing them. The same
for GBoxeds and maybe to some GObjects. GList are a
challenge, as we may own: the list itself (not the
elements), or both the list and elements.
caller-own-return needs to be improved.

Cheers,
Vreixo


      Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento!
http://br.mail.yahoo.com/

[java-gnome-hackers] Fixing compiler warnings

[Andrew C. <an...@op...>]

We've done very well this last week cleaning up things that were leading
to warnings from GCC when compiling the JNI code.

Vreixo sorted out bug #516805 for us, adding a missing cast that knocked
off 47 warnings.

Friday I added a bit of code to add a NULL to functions taking variable
length arguments so that they don't complain about a missing sentinel.
That cleared 15 more warnings.

And I also realized some of the warnings was due to bad .defs data for
TreeViewColumn. That's 2 more.

I'm quite pleased that none of the warnings above were actual problems,
just code hygiene.

We're down to 17 warnings now. That's pretty good. There seems to be one
thing that repeats a fair number of times, so if we can clear that off
we'll finally be at the point where the signal-to-noise ratio means we
won't lose sight of real problems, which is the real point of the
exercise. Awesome.

AfC
Sydney

Re: [java-gnome-hackers] Possible directions

[Andrew C. <an...@op...>]

On Fri, 2008-02-29 at 07:37 -0300, Vreixo Formoso Lopes wrote:
> Sure. But anyway all new features should be present in
> our .defs data, we would then choose what features
> actually expose.

Yes, that's correct.

AfC
Sydney