Re: get_child() APIs

[Emmanuele Bassi <ebassi gmail com>]

hi Benjamin;

On 9 December 2011 10:31, Emmanuele Bassi <ebassi gmail com> wrote:

>> And a node basically has these fields:
>> class Node {
>>  Node parent;
>>  Node previous_sibling;
>>  Node next_sibling;
>>  Node first_child;
>>  Node last_child;
>> };
>
>> If you were to use this for ClutterActor or GtkContainer, you'd have
>> to maintain the list yourself and can't use GList, GSequence or
>> GArray.
>
> yes, I thought about using a GQueue-like structure to get at least
> first/last child, as well as an inline list. the current
> implementation is mostly there because we went for the simple case,
> and at the end of the day, we still have public API that expects
> lists.

I took a couple of days to implement this in a sensible way, and it
turned out to be easier than expected - luckily, I had a test suite to
check. :-)

anyway, I reorganized the Clutter scene graph using the Webkit Node
class as a template, and here's the commit:

https://github.com/ebassi/clutter/commit/7327cecb6fda0422e4a0e4ef3262987ea225de3d

we still need to retain the current behaviour of
set_parent()/add_child(), i.e. sorted insertion depending on the
ClutterActor:depth property, as we want the painter's algorithm we use
inside the paint() implementation of all actors with children to
continue working. I'm still pondering whether we could get away with
tricks like sorting on demand, but for the time being it seems at
least to be an overall win for other operations, like insertion
before/after, as well as raise/lower, as well as general sanity of the
scene implementation.

ciao,
 Emmanuele.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi/