Fix bugs relating to empty GroupLayers

[willGraham01]

Description

What is this PR

• Bug fix
• Addition of a new feature
• Other

Why is this PR needed?

Currently there are a number of issues when working with empty GroupLayer objects:

• [BUG] Seg-fault when adding an empty group to an empty group #12
• Adding a Layer via drag-and-drop to an empty GroupLayer when there are other empty GroupLayers in the tree causes the Layer to be added to the first empty GroupLayer, not the selected one.
• We hit sporadic recursion errors when attempting to put GroupLayers inside other GroupLayers.

The above issues are caused by the comparison operation == on GroupLayer: this is inheriting from a napari object (TypedMutableSequence) which compares the ._list attributes of the GroupLayer. Since empty lists are equal, thus it is that empty GroupLayers are equal. In particular, this means that asking the GroupLayer.index method for the index of an empty GroupLayer, the index of the first such GroupLayer would be returned and not necessarily the GroupLayer we were concerned with!

• This caused [BUG] Seg-fault when adding an empty group to an empty group #12 since it meant that a GroupLayer was to be placed inside itself (moving an empty GroupLayer inside a GroupLayer resulted in moving the first empty GroupLayer inside itself as references were incorrect).
• Likewise, we hit occasional recursion errors because the selection propagation would continually propagate a selection to an object with a reference to itself.
• And dragging-and-dropping Layers always got added to the first empty group (if placed into any such empty group) because the index method would point to the first empty group in the list.

What does this PR do?

Implements an explicit __eq__ method for the GroupLayer class, which fixes the issue of comparison. Since the GroupLayerControls need to use the GroupLayers as keys, they must also be hashable, so we also need an appropriate __hash__ method. Use of id(self) is not sufficient because the way napari works when moving objects is to delete them and instantiate a copy, thus changing the memory address of said object and hence id(self) is not invariant!

As a result, GroupLayer (the class) now tracks a __next_uid int which serves as our hash value for a given instance. When an instance is created, the uid property is set to the next available value, and then the next available value increments by 1. __hash__ can then fetch the uid attribute which has all required properties of a hash, and __eq__ can now be overwritten.

This does mean that we have the following (somewhat unintuitive) behaviour for GroupLayers now: two GroupLayer instances, instantiated with the same inputs, will not be equal (by neither == or is).

However, I would argue this is actually desirable from our POV. GroupLayers are an organisational tool, so two instances that contain the same nested structure should not be considered equal. The user may want to have one visible and the other invisible, for example. Or one translated relative to the other, with a different level of saturation / contrast, etc.

References

Closes #12. It also fixes the (unreported & aforementioned) bug @alessandrofelder found concerning moving Layers into empty GroupLayers.

How has this PR been tested?

Is this a breaking change?

Does this PR require an update to the documentation?

We can cross off one "breaking issue" from the section we have in the README 😄

Checklist:

• The code has been tested locally
• Tests have been added to cover all new functionality (unit & integration)
• The documentation has been updated to reflect any changes
• The code has been formatted with pre-commit

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.66%. Comparing base (cf74dec) to head (df41d9c).

Additional details and impacted files

@@                Coverage Diff                 @@
##           ARC-dev-branch      #38      +/-   ##
==================================================
+ Coverage           89.36%   89.66%   +0.30%     
==================================================
  Files                   8        8              
  Lines                 470      484      +14     
==================================================
+ Hits                  420      434      +14     
  Misses                 50       50              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.