Fixes legend.get_children() to actually return the real children of

[cimarronm]

legend while not including descendents who are children of other
objects (what would be grandchildren, great grandchildren, etc.)

[cimarronm]

The main problem here is that legend erroneously (my viewpoint of what a child is) returns not only children but other descendants as well (i.e. grand children, great grand children, etc.). In doing so, one can no longer use the get_children method to build a true traversal tree for objects underneath it.

Thus, functions like the picker in the artist will not behave correctly and end up calling descendants more than once as they attempt to traverse the object tree as you see in the artist code excerpt below. This is what results as seen in the bug for issue #1962.

        # Pick children
        for a in self.get_children():
            # make sure the event happened in the same axes
            ax = getattr(a, 'axes', None)
            if mouseevent.inaxes is None or mouseevent.inaxes == ax:
                # we need to check if mouseevent.inaxes is None
                # because some objects associated with an axes (e.g., a
                # tick label) can be outside the bounding box of the
                # axes and inaxes will be None
                a.pick(mouseevent)

This PR removes descendants from legend.get_children() who are not direct children of the legend itself.

[tacaswell]

I don't really understand why this works (or more precisely, why it used to work when the legend was inside the axes), but it does.

👍 to merge from me.

[mdboom]

Cc: @leejjoon, @pelson as people who have far more experience with the legend code than I. Any ideas why it currently behaves the way it does? I buy @cimarronm's argument that get_children returns more than just its own children, but seemingly it must do that for a reason...?

[pelson]

In doing so, one can no longer use the get_children method to build a true traversal tree for objects underneath it.

I'm not sure the method (despite its name) is designed for that purpose. @mdboom mentioned the other day that DOM type traversal would be a great addition, but that wouldn't have to be shoe-horned into existing methods necessarily.

All of the above said, I know of no reason why get_children needed to add these non-direct descendants to the list, and in principle, provided it doesn't break anything I'm OK with changing it.

[tacaswell]

I do wonder how much code gets left in strange states because 'it must be that way for a reason....'