Show scalebars in ortho views #3049
Conversation
There was a problem hiding this comment.
Nice, looking very good :)
What do you think about this alternative design:
This way we would "waste" less space and not obstruct as much data :)
I removed the white bar div and added this css to the zoom level div:
border-bottom: 1px solid;
border-left: 1px solid;
border-right: 1px solid;
| @@ -91,6 +91,13 @@ export type ContourModeType = $Keys<typeof ContourModeEnum>; | |||
| export const NODE_ID_REF_REGEX = /#([0-9]+)/g; | |||
| export const POSITION_REF_REGEX = /#\(([0-9]+,[0-9]+,[0-9]+)\)/g; | |||
|
|
|||
| // The plane in orthogonal mode is a little smaller than the viewport | |||
| // as there are two borders with width 2px each => 8px | |||
| // TODO: Wouldn't 2px on each side only result in 4px additional width instead of 8px? | |||
There was a problem hiding this comment.
There are 2 borders, like this: ||...data...||, the yellow and the red border for example, each border is 2px in width, so 2x2px on the left and 2x2px on the right, making 8px.
There was a problem hiding this comment.
Ahh, ok, I thought the input catcher border wouldn't be counted and misread the "two" in the sense of left and right. Thanks for the clarification 👍
| @@ -127,6 +132,11 @@ class UserSettingsView extends PureComponent<UserSettingsViewProps> { | |||
| value={this.props.userConfiguration.displayCrosshair} | |||
| onChange={this.onChangeUser.displayCrosshair} | |||
| /> | |||
| <SwitchSetting | |||
There was a problem hiding this comment.
We should get rid of this code duplication at some point, the volume settings contain exactly the same settings as the plane tracing settings (minus the clipping distance). Not your job in this PR though :)
There was a problem hiding this comment.
Yeah, the custom viewport branch cleans this up, so this will be only temporary hopefully :)
| }} | ||
| > | ||
| <div>{formatZoomLevel(calculateZoomLevel(flycam, dataset) * scalebarWidthPercentage)}</div> | ||
| <div style={{ width: "100%", height: 10, padding: 4, background: "white" }} /> |
There was a problem hiding this comment.
I'd suggest a color like rgba(255,255,255,0.6) here, so the white bars are somewhat transparent and not that eye-catching.
There was a problem hiding this comment.
Or opt for my alternative design proposal
| // The plane in orthogonal mode is a little smaller than the viewport | ||
| // as there are two borders with width 2px each => 8px | ||
| // TODO: Wouldn't 2px on each side only result in 4px additional width instead of 8px? | ||
| export const OUTER_BORDER_ORTHO = 2; |
There was a problem hiding this comment.
I'm seeing some movement to the outer edge by the scalebar when scaling with K/L. Maybe this will be fixed when changing this value to (the more correct?) 4, but it's just a guess.
There was a problem hiding this comment.
The actual border size also depends on the scale which would need to be incorporated. However, I managed to do this completely with percentages in css (since the border will always be approx. 2% of the input catcher).
…or arbitrary modes
Awesome, I really like it! I changed the code accordingly :) |
This PR adds the option (disabled by default) to show scalebars in the ortho views. For the arbitrary views, it doesn't make much sense in my opinion, since the view is completely distorted (at least, for flight mode). For oblique, we could theoretically calculate it, but not sure if there is much value. Do you agree @daniel-wer ?
Also, I decided to always make the scalebars 25% width of the actual viewports. Another approach would be to make sure the scalebars always display a "round" amount of nm/µm. However, this would be a bit more complicated to implement, and might also be annoying if they change the size all the time. With the current approach, you can always "measure" a cell slice by just scaling the viewport the right way.
URL of deployed dev instance (used for testing):
Steps to test:
Issues:
Todo: