On Sat, Jan 25, 2014 at 10:46 AM, Axel Simon <axel.si...@in.tum.de> wrote:
> Hi Donald,
>
> it's been a while since I've implemented this, so I can at best convey my gut
> feeling about this.
>
> It would be good to understand when and where the outdate TreeIter is used.
The TreeIter is not used in the callback, as I mentioned in my
original post. I use the supplied path instead to add the
grandchildren. I never touch or use the iter.
I suspect that your callback to testExpandRow does return normally
That's correct, also mentioned in my original post. I established that
with debugging print statements.
(do you return True?)
No. Returning True would disallow the expansion (see the GTK
documentation on the treeview's test-expand-row signal). I return
False, to allow the expansion.
and then some other call back is called with the now outdate TreeIter
that is handled by Gtk (which then creates these warnings).
I don't think the warning is coming from Gtk. I think it's coming from
gtk2hs/gtk/Graphics/UI/Gtk/ModelView/Gtk2HsStore.c
static gboolean
gtk2hs_store_iter_has_child (GtkTreeModel *tree_model,
GtkTreeIter *iter /* in */)
{
WHEN_DEBUG(g_debug("calling gtk2hs_store_iter_has_child\t(%p,
%p)\n", tree_model, iter));
Gtk2HsStore *store = (Gtk2HsStore *) tree_model;
g_return_val_if_fail (GTK2HS_IS_STORE (tree_model), FALSE);
g_return_val_if_fail (iter->stamp == store->stamp, FALSE);
<<<<<<<<<<<<<<<<<--------------------------------------
gboolean result = gtk2hs_store_iter_has_child_impl(store->impl, iter);
WHEN_DEBUG(g_debug("return gtk2hs_store_iter_has_child\t=%s\n",
result ? "TRUE" : "FALSE"));
return result;
}
I think this assertion is just wrong. It's assuming that the
time-stamp on the store can't change in a callback that involves a
time-stamped iter. That's not true, as I've demonstrated. This all
works correctly in my C version. (The statements I've made about what
I think is right and wrong are based on a very cursory -- pun intended
-- understanding of the gtk2hs code, so it's possible I'm all wet. I
don't think so, but it's possible. This needs to be looked at by
someone who really understands the code.)
You might be able to find out which callback is fired by connecting
to various likely ones and printing messages, possibly printing the
TreeIter.
>
> In the extreme case, C would allow you to destructively change the stamp
> while in the callback. That is hopefully not what the developers intended,
> also because it's not obvious to what the stamp should be set.
>
> I hope this helps a bit.
Thanks for trying. Perhaps your message has prompted me to make things
a bit clearer.
If there is a fix or something general rule, maybe we can add a
comment to the signal so that other people know?
I think there's just a bug in the code. Adding documentation isn't
going to fix it at this point. I make this statement because I'm able
to accomplish what I described quite easily in my C version and should
be able to do so in Haskell. I believe the bug is in the gtk2hs layer,
as I described above.
/Don
>
> Cheers,
> Axel
>
>
>
> On 24.01.2014, at 06:52, Donald Allen <donaldcal...@gmail.com> wrote:
>
>> I've written a personal finance manager, having become dissatisfied
>> with Gnucash after many years of use. My own system, Newcash, is
>> written in C/GTK3/Sqlite3 (I will be making it available via github
>> when the documentation is ready). In recent months, I've become
>> interested in Haskell (I've written a lot of Lisp and Scheme code over
>> the years) and I re-wrote the Newcash report generator (originally
>> written in Python to process Gnucash's xml file and thus was pretty
>> ugly and needed re-writing) in Haskell. Enthusiastic about the
>> language and pleased with the performance of the report generator, I
>> decided to experiment with re-writing Newcash itself in Haskell, for
>> all the reasons that Haskell is to be preferred to C.
>>
>>
>> But I've run into a show-stopper. Here's the situation: the Newcash
>> initial window displays the tree of accounts. Not wanting to endure
>> long startup times (a big issue with Gnucash), I initially want to
>> populate the tree model with the root, its children, and its
>> grandchildren. The root gets expanded, so the children are visible,
>> but the grandchildren are present, so the children are expandable. A
>> callback is set up to handle the TreeView's testExpandRow signal,
>> indicating that the user has requested expansion of one of the nodes.
>> I do this initial setup of the accounts window prior to calling
>> mainGUI the first time. This all works fine.
>>
>>
>> The trouble starts if I try to expand one of the root's children by
>> clicking it. The root's grandchildren are already present, but
>> callback attached to the testExpandRow needs to add the grandchildren
>> of the clicked node, so that if it has children, it will appear
>> expandable. The callback receives both an iter and a path to the
>> clicked node. It uses the path in a loop that adds the grandchildren
>> of the clicked node to the TreeStore. This succeeds, but when the
>> callback returns, I get an error message:
>>
>>
>> ** (Newcash:920): CRITICAL **: gtk2hs_store_iter_has_child: assertion
>> 'iter->stamp == store->stamp' failed
>>
>> and the display fails to refresh, with the clicked node expanded. If I
>> click the same node again, it expands correctly (the grandchildren are
>> already present, courtesy of the response to the previous click).
>>
>> I'm guessing that the iter being passed to the callback (which I don't
>> use; as mentioned before, the insertion of the grandchildren is done
>> using the path derived from the path of the clicked node, using
>> treeStoreInsert) has a time-stamp as of the time the first
>> testExpandRow signal was issued. In response to that signal, I add
>> some nodes to the store. I'm guessing that doing so updates the
>> time-stamp on the store and that the two time-stamps are compared upon
>> return from signal processing, and they are no longer equal. The
>> second click does nothing to the store (my callback is smart enough to
>> know that a node has already been processed and doesn't add its
>> grandchildren twice), so the second time the node is clicked, the
>> time-stamp comparison works.
>>
>> ------------------------------------------------------------------------------
>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>> Critical Workloads, Development Environments & Everything In Between.
>> Get a Quote or Start a Free Trial Today.
>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Gtk2hs-devel mailing list
>> Gtk2hs-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
>
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Gtk2hs-devel mailing list
Gtk2hs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
