Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #304 +/- ##
==========================================
- Coverage 86.84% 86.75% -0.09%
==========================================
Files 89 90 +1
Lines 5077 5120 +43
==========================================
+ Hits 4409 4442 +33
- Misses 668 678 +10 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
mariobuikhuizen
left a comment
There was a problem hiding this comment.
Looks good!
I see a few issues in a vue template:
6f1f778 to
bc67c56
Compare
|
The solution for the problem with margins inside the jdaviz sidebar is to use |
|
And add some margin between the glue-float-fields with |
bc67c56 to
cae81df
Compare
There was a problem hiding this comment.
This is a great start, thanks! It would indeed be nice for the limits to be updated only once the user has finished entering values, otherwise typing e.g. 1000 means the limits will change four times (1, then 10, then 100, then 1000). Maybe @mariobuikhuizen and @maartenbreddels have ideas how to deal with this? I think this would solve the aspect ratio issue you mention for the image viewer. Other than that, I'm happy with this, and we can add it to other viewers in a separate PR.
Co-authored-by: Mario Buikhuizen <mbuikhuizen@gmail.com>
9779af8 to
a072709
Compare
|
@kecnry I've pushed some commits here to add the 'Apply limits' button. Do you think this seems ok? |
| with delay_callback(self.glue_state, 'x_min', 'x_max', 'y_min', 'y_max'): | ||
| if self.x_min is not None: | ||
| self.glue_state.x_min = self.x_min | ||
| if self.x_max is not None: | ||
| self.glue_state.x_max = self.x_max | ||
| if self.y_min is not None: | ||
| self.glue_state.y_min = self.y_min | ||
| if self.y_max is not None: | ||
| self.glue_state.y_max = self.y_max |
There was a problem hiding this comment.
when used in an image viewer (now enabled), how is a change in all limits, with equal aspect enabled, handled with this delayed callback? From testing, it seems that the user-set x-limits are preserved and the y-limits are somehow adjusted to enforce the equal aspect?
I'm honestly not sure what the expected behavior should be in this case... maybe the smallest bounding box in x and y that contains the user-provided values?
Description
This pull request adds axes limits to the viewer options for profile and image viewers.
In theory this could be extended to other viewers, although handling aspect ratio within image viewers will require additional logic (currently the aspect ratio is enforced at every keypress, which overwrites the value typed by the user, making the axes limit editing effectively useless while equal aspect ratio is enabled).