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

Re: [java-gnome-hackers] GtkCellRendererCombo - help appreciated

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

On Tue, 2008-05-13 at 23:35 +0200, Stefan Prelle wrote:
>     setPropertyObject("model", model)

>   unable to set property 'model' of type 'GtkTreeModel' from value of
>   type 'GObject'

Ah. That would seem to be a bug.

It _might_ be the same class of problem that we recently ran into with
GValues holding enums: for some reason GValue gets grumpy when asked to
hold abstract types. See 'textview' revno 508.

Actually, the real bug is that we didn't have any test coverage of
setPropertyObject(); at least we had somethine for getPropertyObject().

Which raises a different question: why does the get path work and not
the set path? The GValues are being initialized the same way, aren't
they? Answer, no, not quite: the GValues in property getting are created
C side in our GObject.g_object_get_property() implementation using the
GParamSpec.

So we'll either have to do the enum hack again, or change the way
GObject.setProperty() works so that it creates the GValue C side.

What a pain. I hate GValues.

In fact, I'd be happy if they went away entirely. That would mean making
GObject.setProperty(), GtkTreeView.setValue()  and anything else that
uses GValue have a native overload for every type combination [in a
hand written Override]. That *is* doable, but at present we have all
those code paths concentrated through the Value code paths.

Well, whatever. Something for the future.

AfC
Sydney

[java-gnome-hackers] GtkCellRendererCombo - help appreciated

[Stefan P. <st...@pr...>]

Hi all,

I am trying to figure out a way to set the "model" property of the
CellRendererCombo to provide coverage for this type.

* I tried providing a method 
  void org.gnome.gtk.CellRendererCombo.setModel(TreeModel model) {
    setPropertyObject("model","model)
  }
  (using GObject.setPropertyObject()) and received a warning

  unable to set property 'model' of type 'GtkTreeModel' from value of
  type 'GObject'

* I also tried to use store the TreeModel in a different column
  by using a DataColumnReference (which I hoped would simply store
  the object)
  void CellRendererCombo.setModel(DataColumReference column) {

GtkCellLayout.addAttribute(vertical,this,"model",column.getOrdinal());
  }

  unable to set property 'model' of type 'GtkTreeModel' from value of
  type 'BindingsJavaReference'

It seems I am just missing a method which retains the intended type
until finally calling GTK. But after some blind digging through the
generated code (and not having the JNI overview) I must admit that I
don't know how to proceed.

Any idea/hint/help is welcome.

Regards,
  Stefan

Re: [java-gnome-hackers] TextBuffer TextIter methods

[Stefan P. <st...@pr...>]

Am Freitag, den 09.05.2008, 17:40 +1000 schrieb Andrew Cowie:
> I am chafing at the asymmetry between TextBuffer and TreeModel's
> "iterator" retrieving methods. I am therefore considering presenting our
> public API as:
> 
>         getIterStart(),
>         getIterEnd(), and
>         getIter(TextMark)
> 
> instead. The completion space at getIter<COMPLETE> looks a lot better.

I think that is a good idea. 

I am not totally sure about the name "getIter(TextMark)" resp.
"getIter(TreePath)". Maybe a "getIterAt(TextMark)" or
"getIterFrom(TextMark") would give a better hint that this is basically
a conversion method.

Cheers,
  Stefan

[java-gnome-hackers] TextBuffer TextIter methods

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

Another minor design question. In TreeModel one finds methods like:

        getIterFirst()     
        getIter(TreePath)  // convert a TreePath

returning TreeIters.

In TextBuffer, there are:

        getStartIter(),
        getEndIter(), and
        getIterAtMark(TextMark)

which return TextIters.

Uniformity is important, so yYou can probably guess where I'm heading.

I am chafing at the asymmetry between TextBuffer and TreeModel's
"iterator" retrieving methods. I am therefore considering presenting our
public API as:

        getIterStart(),
        getIterEnd(), and
        getIter(TextMark)

instead. The completion space at getIter<COMPLETE> looks a lot better.

AfC
Sydney

Re: [java-gnome-hackers] CellRendererText.EDITED - String to TreePath?

[Stefan P. <st...@pr...>]

Hi,

Am Mittwoch, den 07.05.2008, 12:18 +1000 schrieb Andrew Cowie:
> It strikes me that this
> should already have been done for you, and that the signature in our
> bindings should be:
> 
>         public void onEdited(CellRendererText source, TreePath path, String newText);
> 
> which would be more in line with signals like TreeView.ROW_ACTIVATED.

I noticed that too and I think a TreePath would be a lot better instead
of a String.

Stefan

[java-gnome-hackers] CellRendererText.EDITED - String to TreePath?

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

I received a patch from Stefan Prelle with some nice improvements. I was
about to merge it, but one thing that caught my eye.

CellRendererText has an EDITED signal, the prototype for which is:

        public void onEdited(CellRendererText source, String path, String newText);

the second argument is what's bothering me: it's a symbolic location
into the backing TreeModel. Stefan wrote a nice little example into the
javadoc, but when I read it I realized that the first thing that one
does with said path is turn it into a TreePath. It strikes me that this
should already have been done for you, and that the signature in our
bindings should be:

        public void onEdited(CellRendererText source, TreePath path, String newText);

which would be more in line with signals like TreeView.ROW_ACTIVATED.

[Obviously I am the one normally arguing that we don't change mappings
without a good reason, but this appears to me to be in the
being-strongly-typed category. So I'm not asking if it's "ok", just if
someone knows a reason why the String form would be more useful to
people hooking up to that signal than a TreePath]

AfC
Sydney

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

[Stefan P. <st...@pr...>]

Am Sonntag, den 04.05.2008, 16:23 +1000 schrieb Andrew Cowie:
> > 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.

Ok, glad to know I didn't miss anything.

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

The thought to look at TreeIter (or other iterators) did not cross my
mind. :) Shame on me.

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

I did some work on the 'textview' branch and I have it working now. You
will get it per email in a few minutes.
Having at least minimal (without tags) TextView coverage in java-gnome
is something that should be included in the mainline with the next
release. You cannot build GUIs with simple multiline textfields without
it, which I consider an important feature.
So, I think I'll help you on that branch - although I have no experience
with tagged TextBuffers yet. But that can be changed in the process.

Cheers,
  Stefan

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

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

[Stefan P. <st...@pr...>]

Hi all!

First of all: Andrew "tricked" me into having a closer look at the
sources and do needed coverage of GTK methods myself, so I just found
myself digging through the sources. I hope I can help you add some
coverage in the future.

I started working on coverage for TextBuffer/TreeView and friends and
nearly immediately stumbled into my first problem, for which I request
your advice.

I want to write a method
  TextIter TextBuffer.getStartIter()

Having a look at GtkTextBuffer I found
  static final void getStartIter(TextBuffer self, TextIter iter) {
    ..
    gtk_text_buffer_get_start_iter(pointerOf(self), pointerOf(iter));
    ..
  }

So, I need an instance of a TextIter to call that method - but where do
I get that from? Normally I would expect a native method like 
  gtk_text_iter_new
but it seems that it does not exist.

The GTK API docs claim that "... GtkTextIter is a struct designed to be
allocated on the stack; ...", so normally I would call it like
  GtkTextIter start_iter;
  GtkTextBuffer foo = ...;
  gtk_text_buffer_get_start_iter (&foo, &start_iter);

This is basically what is in GtkTextBuffer.c 
Java_org_gnome_gtk_GtkTextBuffer_gtk_1text_1buffer_1get_1start_1iter
except that that method requires a pointer to a GtkTextIter, although it 
should be the method to create one.

Manually patching GtkTextBuffer.c is out of the question, since it is 
generated, so now I am stuck.

Can anyone shed some light on this. Did I miss something? Any idea how to 
solve this?

Cheers,
  Stefan
  Germany, Bremen

[java-gnome-hackers] java-gnome 4.0.7 released

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

I am pleased to announce a new release of the java-gnome user interface
library.

Tarballs of 4.0.7 can be downloaded from:
http://ftp.gnome.org/pub/GNOME/sources/java-gnome/4.0/ 

Release notes are, as usual, in the NEWS file:
http://java-gnome.sourceforge.net/4.0/NEWS.html#4.0.7

++

Serkan Kaba was mentioned as one of the people to whom credit is due;
Serkan is a long time participant in #java-gnome who took the time to
test building the 4.0.7-rc1 release candidate. Doing so he uncovered a
problem whereby String's toUpperCase() was behaving unexpectedly and
breaking the build as a result. Turned out to be a side effect of the
Turkish locale and that while Character.toUpperCase() is deterministic
in the face of changing locales, String.toUpperCase() is not. Serkan,
having seen this sort of problem with other (otherwise mature) Java
projects, was able not only to help pin down the cause but also
contributed the fix as well.

I mention this because this is the sort of bug that is bigger than any
one person or organization. They lurk in every project. It serves as an
nice reminder of the outstanding quality of Open Source as a software
development process. Thanks Serkan!

AfC
Sydney

--
Maintainer,
java-gnome
The GNOME user interface library for Java

Partner,
Operational Dynamics
Crisis resolution, change management, and leadership development

[java-gnome-hackers] Glade files

[Johan G. <joh...@li...>]

Hi all,
I've tried to build a little program using Java Gnome 4.0.6 and a Glade 
project. But there seems to be missing a very important function and 
that is glade_xml_signal_autoconnect. Without it no widgets are bound to 
any functions so nothing works in gui. Any plans on when it will be added?

Regards,
Johan

[java-gnome-hackers] 4.0.7-rc1 up

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

I've done a release candidate for java-gnome 4.0.7

As described before, there's nothing requiring us to do RCs; but they
have proved useful. This time around, there are two audiences:

One, people doing packaging can check and make sure that 4.0.7 is all
sorted for them. Remember that the goal is that *zero* configuration and
build related patches be necessary; after all, we want people to be able
to build & hack on java-gnome itself if building it themselves from
source and if a distro's packages have a huge patch set then we aren't
doing our job to support them.

Second, people with serious apps wishing to use 4.0.7 as the release
they depend on for their own next release can check that stuff they
_really_ need is in there.

I have delayed the release of 4.0.7 until 27 April or so. I are moving,
and so I will be off the direct internet for the next week (at least, I
hope it's not any longer than that. {sigh}, telcos. I will be able to
get email intermittently; if you want to chat, use the mailing lists.

Cheers,

AfC
Sydney

-- 
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] Possible Bug in Cairo bindings when exporting to PNG

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

On Tue, 2008-04-15 at 22:49 +0000, Vreixo Formoso Lopes wrote:

> +public class SVGSurface extends Surface
> 
Yup.

> +    public static final Status WRITE_ERROR = new ...

That's fine, of course. When a Constant is needed it's needed.

I usually try to do all the Constants when adding something, but
sometimes when it's a really long list of things that for which I don't
know what they all do, I do the ones I can figure out / am using.

You came across a case of needing that Constant, so add it, no question.

> -    public void writeToPNG(String filename) {
> +    public void writeToPNG(String filename) throws IOException {

That's fine, but maybe do the access check _before_ calling Cairo? ie
File's canWrite()

> 
> -        surface.writeToPNG(OUTPUT_FILENAME);
> +        try {
> +            surface.writeToPNG(OUTPUT_FILENAME);
> +        } catch (IOException e) {
> +            fail("Unexpected file write error");
> +        }
> 
That's fine, but we should probably improve the 


>      public final void testImageSurfaceWriteToPNG() {

test to actually verify this behaviour.

In other words, a better test would be to try writing to a known
unwritable path and test that the exception _does_ happen.

Then test writing to a path that known to work (ie, tmp/tests/) and make
sure that the exception does _not_ happen.

[That test case class is still rather a work in progress. What I wanted
to do was draw something and then positively test that the correct image
was drawn, but that's a bit of a tough proposition]

AfC
Sydney

-- 
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] Memory management branch created

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

On Thu, 2008-03-27 at 23:52 -0300, Vreixo Formoso Lopes wrote:
> Please take a look at my memory management

Spent the day reviewing and testing. I've merged it to 'mainline'.

AfC
Sydney

Re: [java-gnome-hackers] TreeStore unit tests

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

On Thu, 2008-04-03 at 22:12 -0300, Vreixo Formoso Lopes wrote:
> Attached...

Accepted.

And with that, 'treestore' branch merged to mainline.

AfC
Sydney

Re: [java-gnome-hackers] i18n support

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

On Sat, 2008-03-22 at 14:53 -0300, Vreixo Formoso Lopes wrote:
> I send you a little patch that add i18n support for
> java-gnome.

Thanks to Vreixo for having submitted this.

Having just invested three days of work cleaning it up, this branch is
about ready for merging [ie, I would do it now, but it's 01:30 and
that's not a good time to be merging code to 'mainline' that introduces
major changes :|]

See branch 'i18n' in hackers/andrew/.

In addition to a fairly massive editorial effort on the documentation, I
have added a fairly sweeping set of test cases and validated the
preliminary example that was submitted.

        [A patch of this importance without unit tests! What the hell?]

I then attempted to use this code to internationalize one of our own
applications. This uncovered a number of data corruption bugs due to
misuse of the underlying gettext library calls.

        [Guys, if you make C calls, you must read the man page and
        honour issues like "the return value is statically allocated, so
        don't change it." I would say that I simply won't accept patches
        with these sorts of problems, but it usually takes several hours
        of work to discover. Attention to detail would be appreciated.
        "It works!" is not really the ideal]

++

Bringing proper GNOME translation infrastructure into java-gnome is a
terrific initiative. I'm very excited to welcome this.

Remaining issues are:

a) further error checking. The underlying library is pretty useless if
the locale in force is not applicable and worse, if the parameters
supplied to Internationalization.init() are bogus nothing really
happens. We need to do quite a bit better here.

b) a slightly better example, perhaps? Last I spoke to him, Vreixo was
thinking about something.

c) another editorial pass (by someone else) on the text in
Internationalization. Someone who knows the translation tool chain a bit
better than I will no doubt have some improvements to suggest.

It'd be nice to get this squared away before 4.0.7 (which will be within
a week or two).

AfC
Sydney

-- 
Andrew Frederick Cowie
Managing Director
Operational Dynamics Consulting, Pty Ltd
http://www.operationaldynamics.com/

[java-gnome-hackers] Memory management branch created

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

Hi!

Please take a look at my memory management branch at

http://research.operationaldynamics.com/bzr/java-gnome/hackers/vreixo/memmanag/


it improves quite a lot our current memory management
model. It needs testing.

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] Memory management improvements

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

Hi!

I have beginning to work on fixing memory management
issues. The attached patch adds the needed
infraestructure to our code generator, and also
improves the memory management for GObjects. This fix
the bug I told you yesterday, and also the problem
found in FileChooserDialog unit test.

Please test it, but do not merge it to mainline yet.
New memory management model still needs more testing
before being stable.

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] Memory management bug

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

Hi!

Finally I have found an example of one of the memory
management problems I told you some months ago. It is
related with GObjects that are created inside Gtk+.
I've demonstrated with with TreeView.getSelection,
please try to execute the Unit tests after applying
the attached patch.

I know how to handle this, but before that please read
again the attached doc (it is a mail I sent some
months ago) and write your opinions.

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] Annotation-based glade parsing patch

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

Hi!

I send you a little experiment I've developed these
days. It adds annotation-based support for parsing
glade files. WIth this patch, using a glade file with
java-gnome is as easy as:


@File("path/to/glade/file")
public class MyAppGui extends UI {

    @Widget("window1")
    private Window window;

    @Widget("button1")
    private Button okButton;

    @Widget("button2")
    private Button cancelButton;

    ....

}

It needs more work, but I think it is already in a
usable state. Please take a look at it and write here
your comments. Andrew: I propose you to merge it to
mainline.

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. It would be much better to have a protected method and let its
> subclasses (ListStore, TreeStore...) overwrite it

Approved (as already discussed)

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

Sounds like a good idea. Make sure you [unit] test the hell out of it
though - the relationship between those pseudo TreeModels and their
underlying ("child?!?") model is tricky.

You can add tests to ValidateTreeModel or a new class as you see fit.

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

I implemented that this week, actually, but it was crashing on me (due
to something else), so that's when I decided to change the error
behaviour. I've already merged my work into the 'treestore' branch you
sent me. I'll publish it in my repo when I get a chance (assuming I
don't finish my part and merge it to 'mainline')

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

I always recommend people (and wrote up the docs to this effect) to add
a column to their model that contains the sort ordering and then just
tell the TreeViewColumn to sort based on that column. Quick, easy, and a
hell of a lot less effort than calling back to Java every time.

So it's not something I need personally.

If you really do need it, go ahead. You can use TreeModelFilter's
VISIBLE signal & setVisibleCallback() as a roadmap. The interesting bit
is in GtkTreeModelFilterOverride.c

Kinda sucks that those are on TreeSortable and not just on
TreeModelSort. It will therefore be a pain in the ass to implement
everywhere. I would imagine you have better things to do.

Personally, I'd stick with sorting on a known column via
TreeViewColumn's setSortColumn() or TreeModelSort's setSortColumn().


> 4. DataColumnPixbuf has a bug.

The fix for that you submitted has been merged.

AfC
Vancouver

-- 
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] Thoughts about TreeStore

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

> So here's the question: when you get a ROW_EXPANDED
> event, do you need
> to point at a row [ie call model.getValue() with it]
> or do you then need
> to iterate over the model?

good question! I think iteration from a arbitrary row
is not an use case. Usually you catch ROW_EXPANDED
just to get some of the row values (i.e calling
model.getValue()). But the question is: is that a
problem for us? Can we assume the user is not going to
iterate, and thus leave model to null? In my opinion
this is a bad solution, because in that case we have a
set of TreeIter methods that sometimes work, sometimes
not! It is hard for the developer to figure out in
which situations it is valid or not, even if we
carefully document that. 

In my opinion, we should try to keep the same behavior
for all iterators, despite of where they come from.
Anyway, it is not hard to achieve, it is implemented
in my branch!

And note that other methods that need the model, such
as children(), are really useful in a ROW_EXPANDED
handler, so...

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

Hi Vreixo,

Sorry I didn't reply earlier. Thanks for politely nudging me to ask for
some design calls. Let's see:

On Sat, 2008-03-15 at 15:24 -0300, Vreixo Formoso Lopes wrote:
> 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.

Right.

So we both know the usual way to engineer around this. Before we just
blindly head off down that road, it occurs to me to just copy in the
comment that's around the current TreeIter protected <init>(long)
constructor.

    /*
     * The protected constructor was originally removed entirely, but it turns
     * out we need it for signals like ROW_ACTIVATED. This is a problem,
     * because it means we'd have to jump through *many* hoops to populate the
     * model field. Instead, we just cripple this TreeIter as far as iterating
     * goes but that's ok because you never need to iterate from a TreeIter in
     * a signal callback - it's just used to point at a row, done.
     */
    protected TreeIter(long pointer) {
        super(pointer);

        model = null;
    }

So having thought about this some more, I kinda still feel that this
argument holds. TreeIter-as-thing-that-points-at-a-row and
TreeIter-as-iterating-mechanism are really two entirely different use
cases. It's unfortunate that the same struct is used for both.

More generally, I have just been burned by iterating via TreeIter and
changing something (which I thought harmless) causing the TreeIter to
fail. (solving this is either going to mean using a TreeRowReference[]
and looping over it, or TreeModelSort. Not sure yet). Anyway, I'm even
less impressed with TreeIter than I was.

> Ok, solved in a quite good way. But a bit ugly, sure.

No, it's what's necessary - if one assumes that we can't "cripple" the
TreeIters in such cases.

So here's the question: when you get a ROW_EXPANDED event, do you need
to point at a row [ie call model.getValue() with it] or do you then need
to iterate over the model?

I've never seen the later case **from that iterator** - I _have_
subsequently called getIterFirst() and started from the top - but not
from the original TreeIter supplied by the callback.

All in all, this is a case of C-API-convenience vs
essence-of-the-toolkit. The trick is to figure out which one.

Have a think about the question I asked, and we'll chat again in a few
days.

AfC
Vancouver

[java-gnome-hackers] Annoucing Cairo coverage

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

Hey,

Cairo support is a feature I've been working on for about 6 months now,
and I'm very pleased to be able to bring it into java-gnome.

Behdad Esfahbod was really critical in explaining some basic Cairo
concepts to me started when we were working together at the GNOME Summit
back in October in Boston, and last week at the GTK hackfest in Berlin
Carl Worth was able to help us debug some use cases.

The focus of the work was two fold. Mostly I wanted to put the Plumbing
in place appropriate to make a Cairo binding work. This was straight
forward but non-trivial because Cairo doesn't use GLib as it's
foundation. So type mapping, creating instances, etc took a bit of
figuring out.

The other part, of course, was putting enough coverage in place to
ensure that things were working. Cairo has lots of convenience functions
and tons of obscure uses; no surprise (and no apology) that there's
still lots that will need doing. As ever, I have insisted that people
exposing functionality have a reason to be using it so they can a)
understand why they need it, and b) do a good job of explaining how to
use it. I'm the "people" in this case :) and I must admit that I didn't
have much of a use case driving my work on this. I am therefore pleased
to hear that Carl Worth and his brother Kevin Worth will be using our
Cairo bindings for a family oriented game that they are working on -
that's a real use case that will allow people who really know Cairo to
flesh things out.

Implementation observations:

- if using Cairo to draw for a Widget, you do this in an EXPOSE_EVENT
handler. See the [new] documentation for that signal as a starting
point. There's also an example, Example 

- The Java bias is what you'd expect. Constructors instead of factory
functions, etc. In the case of Widget drawing, you use you use the
Context(Drawable) constructor instead of [whatever] gdk_cairo_create()
[would map to].

- error handling is done automatically. C programmers familiar with
Cairo will be used to doing a bunch of stuff and then checking
cairo_status(). We are calling that compulsively on each call. [Right
now that's in the bindings layer; I expect to move it into the JNI layer
once I touch up a few things in the generator]. If the status check
fails a Java exception is thrown.

One final point:

- after discussing things with Carl, I've decided that there is (at
present) no reason to expose the text rending APIs in Cairo. If you need
to draw text, please implement the necessary functionality in Pango -
which of course uses Cairo, but knows what it's doing. :)

Preliminary Cairo support was one of the two dominoes I wanted to fall
before releasing 4.0.7, so I'm pretty pleased.

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] i18n support

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

Hi!

I send you a little patch that add i18n support for
java-gnome. It is simple, powerfull and easy to use.
Please review it and write here your opinions.

Cheers,
Vreixo


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