8000 Use features instead of properties internally by andy-sweet · Pull Request #7084 · napari/napari · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Use features instead of properties internally #7084

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 12 commits into
base: main
Choose a base branch
from

Conversation

andy-sweet
Copy link
Member
@andy-sweet andy-sweet commented Jul 8, 2024

References and relevant issues

Split from the very large #5477 to make reviewing these changes easier.

Description

This uses features instead of properties in the implementation details of napari, but does not yet deprecate use of properties. As part of these changes, it also adds the features event to Tracks.events.

The intent of this PR is to make these changes without breaking the tests and without changing the tests. When actually deprecating properties in practice, we may need to modify some of the tests.

@github-actions github-actions bot added tests Something related to our tests qt Relates to qt labels Jul 8, 2024
Copy link
codecov bot commented Jul 8, 2024

Codecov Report

Attention: Patch coverage is 97.63780% with 3 lines in your changes missing coverage. Please review.

Project coverage is 92.88%. Comparing base (a4fa1fa) to head (21746e1).
Report is 146 commits behind head on main.

Files with missing lines Patch % Lines
napari/layers/points/points.py 81.81% 2 Missing ⚠️
napari/layers/tracks/tracks.py 91.66% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #7084      +/-   ##
==========================================
- Coverage   92.95%   92.88%   -0.07%     
==========================================
  Files         618      618              
  Lines       56449    56446       -3     
==========================================
- Hits        52471    52429      -42     
- Misses       3978     4017      +39     

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

@jni jni added this to the 0.5.1 milestone Jul 9, 2024
@andy-sweet andy-sweet marked this pull request as ready for review July 10, 2024 21:22
@andy-sweet
Copy link
Member Author

Marking this ready for review, but understood this won't make it for v0.5.0, so no rush.

One thing I'm still thinking about if I should fully implement the behavior of the current_properties setter. I remember wanting to split this into two functions - the first to change feature defaults, and the second to update selected feature values. But that is inconsistent with the manually specified similar properties like size and symbol.

@andy-sweet andy-sweet changed the title [WIP] Use features instead of properties in implementation Use features instead of properties in implementation Jul 10, 2024
@andy-sweet andy-sweet changed the title Use features instead of properties in implementation Use features instead of properties internally Jul 10, 2024
@brisvag
Copy link
Contributor
brisvag commented Jul 11, 2024

But that is inconsistent with the manually specified similar properties like size and symbol.

I advocated for changing this behavior before (you might remember, see #5748 and #5722 (comment)). I would be in favor now too :)

@andy-sweet
Copy link
Member Author

I advocated for changing this behavior before (you might remember, see #5748 and #5722 (comment)). I would be in favor now too :)

To clarify, you are in favor of something like set_current_features (or maybe set_selected_features) that both changes the default values and updates the features of the currently selected elements/points?

One thing I don't like is the asymmetry between the current_properties getter and setter. But if we had the following API

@property
def feature_defaults(self):
  ...
@feature_defaults.setter
def feature_defaults(self, feature_defaults):
  ...
def set_selected_features(self, values):
  ...

where the feature_defaults getter/setter act as they do now, and set_selected_features effectively acts as the current_properties setter does now (i.e. it will still have the side-effect of setting feature_defaults too), then I'm happier with the separation of concerns and clarity of each.

What do you think?

@andy-sweet
Copy link
Member Author

For some more context, another reason I don't like the current_* property setter's behavior in general (e.g. for things like face_color, size) is because it assumes those attributes are manually encoded (i.e. by some array), whereas they might be just a constant (imagine a GUI widget control the size for all point) or derived from features.

As they're defined in napari, features are only manually encoded (i.e. there are no derived columns), so I'm happier with having the behavior there.

I'd also be open to property getter/setter if that fits better with napari's API.

@property
def selected_features(self):
  ...
@selected_features.setter
def selected_features(self, values):
  ...

The feature values passed to the setter would just need to be broadcast-able to the full table.

@brisvag
Copy link
Contributor
brisvag commented Jul 12, 2024

To clarify, you are in favor of something like set_current_features (or maybe set_selected_features) that both changes the default values and updates the features of the currently selected elements/points?

No, I'm in favour of having two separate concept: set_default_X and set_selected_X. I think all these should be split into those two.

I actually don't think your proposed solution is clearer than what we have currently, it's just differently unexpected ^^'

IMO we shoudl have:

@property
def features_selected(self):
  ...
@features_selected.setter
def features_selected(self, values):
  ...
@property
def features_default(self):
  ...
@features_default.setter
def features_default(self, values):
  ...

And none of them should affect each other.

Similarly, we should have:

@property
def size_selected(self):
  ...
@size_selected.setter
def size_selected(self, values):
  ...
@property
def size_default(self):
  ...
@size_default.setter
def size_default(self, values):
  ...

I understand that the latter makes the gui a bit more cumbersome (two sliders?), and that was the main complaint... but at least programmatically it should be the way to go.

@andy-sweet andy-sweet modified the milestones: 0.5.1, 0.5 Jul 23, 2024
@willingc willingc added refactor Refactoring code base needs:core-review Needs core dev review labels Nov 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs:core-review Needs core dev review qt Relates to qt refactor Refactoring code base tests Something related to our tests
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants
0