Merge lp://qastaging/~3v1n0/libindicator/parent-object-fixes into lp://qastaging/libindicator/0.5

Having indicator-object take care of this makes sense.

In indicator_object_entry_being_removed() and indicator_object_entry_was_added(), the assignment to entry->parent_object should be unconditional and come before the "if (function_pointer != NULL)" blocks, just as the assignment to EntryPrivate's 'visibility' field is.

Also, just wondering aloud -- do we have any use cases where an entry is reparented? Does it make sense to let this field be changed after construction?

On Wed, 2012-01-25 at 13:21 +0000, charles wrote:
> Also, just wondering aloud -- do we have any use cases where an
> entry is reparented? Does it make sense to let this field be changed
> after construction?

No, since they're allocated in the memory space of the object that'd be
nearly impossible. I don't know that we have any way we could limit it
from changing though.

> Having indicator-object take care of this makes sense.
>
> In indicator_object_entry_being_removed() and
> indicator_object_entry_was_added(), the assignment to entry->parent_object
> should be unconditional and come before the "if (function_pointer != NULL)"
> blocks, just as the assignment to EntryPrivate's 'visibility' field is.

Yes, your're right, and it's what I did on first place (see the first commit), but this was breaking the tests.
Because in test_loader_filename_dummy_signaler you're actually setting the entry pointer value to a defined invalid value (5), and you're currently avoiding crashes only because some class functions are set to NULL.

So, I was just wondering what to do here... I'd prefer to change the test by the way.

Ah, that makes sense. dummy-signaler predates this other entry-related code. Its the author probably just threw in a number because he didn't need a real entry, and an int pointer was fast & easy to test.

I agree with you, it would be better to bring the test up-to-date.

On Wed, 2012-01-25 at 15:07 +0000, Marco Trevisan (Treviño) wrote:
> So, I was just wondering what to do here... I'd prefer to change the test
> by the way.

I think changing the test is the right answer. The tests shouldn't
restrict us from doing the right thing in the code that people actually
use.