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