Re: [java-gnome-hackers] Problem with TextIter / Generator

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

On Sat, 2008-05-03 at 23:07 +0200, Stefan Prelle wrote:
> I started working on coverage for TextBuffer/TreeView and friends 

Hey cool. I've just been beginning work on bits of that myself. [note 1,
note 3]

> So, I need an instance of a TextIter [but no way to instantiate one]
> 
Yup. This is a situation we've come across a few times already.

Having worked out coverage of TreeView, it provides a road map for
other complicated APIs. For instance, almost all the bindings layer
methods dealing with TreeIters are nasty this way, the canonical example
being TreeModel's getIterFirst().

++

The general problem class is that things like GValue, GtkTreeIter,
GtkTextIter, GdkFont, etc are not proper objects (and are not even
GBoxeds in some cases) but are merely C APIs sugar. Two aspects to
this:

1) C binding leakage as library API
-----------------------------------

In C, one simply stack allocates such a struct and then passes it in by
reference. Too easy.

Language bindings can't do that, so something that should only exist for
a few milliseconds at most ends up persisting long after until garbage
collection runs. That's just the way it is, but it's annoying (and
something I spent considerable effort in Berlin trying to point out to
GTK hackers that such things, while nice C bindings, are hideous for
language bindings and should not be used in public GNOME library APIs).

The upshot of this is that there is no _new() function in the .defs data
because there aren't _new() constructors for such things in GTK.


2) No code generation of allocators for structs et al
-----------------------------------------------------

We don't yet [note 2] have anything in the code generator as yet to
generate allocators for Boxeds (and structs masquerading as Boxeds). So
you have to write one yourself.

> Manually patching GtkTextBuffer.c is out of the question, since it is 
> generated

That's correct.

But we do have a route around that, of course, necessary for cases where
the generated code doesn't do what we need. They are colloquially known
as Overrides. I am a bit surprised you didn't notice any. Oh well.

> , so now I am stuck.

TreeIter needed a hand-written instantiation function because of (2)
above. See: src/bindings/org/gnome/gtk/GtkTreeIterOverride.{java,c} as
called by TreeIter's <init>().

So if writing TextIter, it will be much the same. Be sure to follow the
architecture conventions at each layer.

AfC
Sydney



Notes,

[1]: The last java-gnome 2.x application we have that remains unported
to 4.0 is something that makes heavy use of TextViews. I remember very
vividly how difficult I found it circa 2004 working with the
TextView/TextBuffer/TextTag family of APIs.

Unlike the equally obscure TreeView/TreeModel APIs (where we were able
to make significant improvements) I'm not too sure yet if there is much
scope for rescuing TextBuffer. That said, across much of java-gnome,
fairly impressive improvement has come from simply having to the Java
bindings become faithful to the underling libraries and be
algorithmically mapped (modulo adding type safety, _not_ exposing
unnecessary crap, and other java-gnome -isms) and already just doing
that seems to have been an improvement.

Anyway, the patterns we developed in TreeView will no doubt serve as a
road map for TextView. I've already found this with TextTag and it
sharing quite a bit in nature with CellRenderer, being GObject property
driven.

[2]: this is only the third or fourth time we've need to write such an
override, and they've been a bit different each time; for Boxeds we
could use the supplied _copy() and _free() functions (and do in the hand
crafted override code), but for plain structs it's all hideously manual.
Lot of extra generator code for such a few number of cases, although it
would be nice to see at some point. Again,
read src/bindings/org/gnome/gtk/GtkTreeIterOverride.c

[3]: I spent a lot of time over the last few days beating TextTag into
submission. The internal GObject property binding mechanism needed a
fair bit of further coverage and fixing, and I added a fairly
significant amount of safety checking as well.

I also did some basic work on a few Pango classes where they are used as
constants in GTK text manipulation. This was nasty: I needed to
introduce something to enable strong type safety for constants that were
double, rather than int, based.

[This is not work on
Pango-as-text-drawing-library-to-be-used-with-Cairo; (Vreixo is
interested in that area) but I did implement the constants that came up
as being necessary in the TextTag properties I wrote setters for].

++

So definitely feel free to merge from my 'textview' branch at
bzr://research.operationaldynamics.com/bzr/java-gnome/hackers/andrew/textview/ 

... but be aware it's very much work-in-progress, no where near
'mainline' ready, and not really something I can afford to be spending
much time on. Nevertheless there is a lot of infrastructure fixing
that's gone on there already, and more that will become necessary. More
to the point it's always good to collaborate with someone working on an
area rather than having their work being duplicate effort.

-- 
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