-
Notifications
You must be signed in to change notification settings - Fork 27
Segment group batch actions #7164
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
Conversation
frontend/javascripts/oxalis/view/right-border-tabs/segments_tab/segments_view.tsx
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
very cool stuff 👍 I left a couple of notes but overall it looks pretty good. other than the refactoring of the per-segment-call code about which we already talked, there is one thing I'm a bit hesitant about: areSegmentsInGroupVisible
. this is state you are maintaining in your component, but it can be affected from the outside. for example, if I rightclick into the data viewport and render a mesh, the segment list won't take note of that right now. similarily, if I use the checkbox next to a mesh to hide it, the list component will also run into an outdated state.
instead, you should probably derive this information from the IsosurfaceInformation
objects in this.props.isosurfaces[segment.id]
(it has a isVisible
prop). you might want to use getDerivedStateFromProps
for that so that you can build your areSegmentsInGroupVisible
state everytime the isosurfaces change.
frontend/javascripts/oxalis/view/right-border-tabs/segments_tab/segments_view.tsx
Outdated
Show resolved
Hide resolved
frontend/javascripts/oxalis/view/right-border-tabs/segments_tab/segments_view.tsx
Outdated
Show resolved
Hide resolved
frontend/javascripts/oxalis/view/right-border-tabs/segments_tab/segments_view.tsx
Outdated
Show resolved
Hide resolved
frontend/javascripts/oxalis/view/right-border-tabs/segments_tab/segments_view.tsx
Outdated
Show resolved
Hide resolved
frontend/javascripts/oxalis/view/right-border-tabs/segments_tab/segments_view.tsx
Outdated
Show resolved
Hide resolved
frontend/javascripts/oxalis/view/right-border-tabs/segments_tab/segments_view.tsx
Outdated
Show resolved
Hide resolved
frontend/javascripts/oxalis/view/right-border-tabs/segments_tab/segments_view.tsx
Outdated
Show resolved
Hide resolved
@philippotto thank you for the review! I'll just quickly respond to the topic on I thought about extracting the visibility from the meshes but I wasn't sure what a good metric in a mixed-visibility group is. If I use the actual isosurface data, is it fine to derive a field called |
Yes, i think it's fine to deal with mixed visibilities like you suggested. I don't have a strong opinion whether hide or show are "preferred". If you find the one variant more intuitive, let's go with that :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great stuff. Please see my comments on naming variables, functions etc and consistency. Otherwise this is works very well.
frontend/javascripts/oxalis/model/actions/annotation_actions.ts
Outdated
Show resolved
Hide resolved
const { segmentMeshController } = getSceneController(); | ||
const zipWriter = new Zip.ZipWriter(new Zip.BlobWriter("application/zip")); | ||
try { | ||
const promises = cells.map((element) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we call this something more specific / less generic? What do these promise hold? Maybe zipWriterPromises
? Or zippedFilesPromises`? Idk
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there is a promise for each file that's added to the zipWriter. (for reference: https://gildas-lormeau.github.io/zip.js/api/index.html) so I think addFileToZipWriterPromises
is long but correct.
frontend/javascripts/oxalis/view/right-border-tabs/segments_tab/segments_view.tsx
Outdated
Show resolved
Hide resolved
frontend/javascripts/oxalis/view/right-border-tabs/segments_tab/segments_view.tsx
Show resolved
Hide resolved
frontend/javascripts/oxalis/view/right-border-tabs/segments_tab/segments_view.tsx
Outdated
Show resolved
Hide resolved
frontend/javascripts/oxalis/view/right-border-tabs/segments_tab/segments_view.tsx
Outdated
Show resolved
Hide resolved
groupTree: generatedGroupTree, | ||
searchableTreeItemList, | ||
prevProps: nextProps, | ||
}; | ||
} else { | ||
} | ||
if (prevState.prevProps?.isosurfaces !== isosurfaces) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure I understand the reason for this code. Can you elaborate please. How can I test this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This code makes sure that changing the visibility of a mesh (e.g. by clicking the checkbox) gets noticed by the segments_view as the visibility is part of the isosurface.
This is needed because I toggle the "Hide/Show meshes" option based on the mesh visibility in the group.
You can test it by loading all meshes in a group. Now, the context menu should say "Hide...". If you deselect any mesh's visibility checkbox, the context menu notices and will then read "Show all meshes".
Does that make sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also see philipps comment for this: #7164 (review)
…s/webknossos into segment-group-batch-actions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
great stuff :) I left some suggestions for simplifying some things further 🤞
@@ -0,0 +1,14 @@ | |||
class TransFormStream {} | |||
|
|||
let mockedWindow = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
whats the purpose of this variable? if it's needed for some reason, you can add a comment to it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Omitting it doesn't seem to break anything, so I left it out.
Just for clarification. Technically this could have been used somewhere else because the scope of the variable is global, right? (https://www.w3schools.com/js/js_scope.asp)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically this could have been used somewhere else because the scope of the variable is global, right? (https://www.w3schools.com/js/js_scope.asp)
The linked article is a bit confusing (generally, w3schools ist not the best resource; I recommend MDN instead). However, the specific MDN article is also not perfect (it mentions module scope, but doesn't really explain when it comes into play).
To answer your question: no, it could not have been used somewhere else because the variable is module-scoped. That scoping is achieved during the compilation/bundling of all the module files. To get a truly global variable, one has to extend window
(in a browser context) or global
(in a node context).
const entries = await reader.getEntries(); | ||
await reader.close(); | ||
const wkwFile = entries.find((entry: Entry) => | ||
const wkwFile = entries.find((entry: any) => |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just pushed a commit (I hope the CI passes), which improves the typing a bit.
frontend/javascripts/oxalis/view/right-border-tabs/segments_tab/segments_view.tsx
Outdated
Show resolved
Hide resolved
frontend/javascripts/oxalis/view/right-border-tabs/segments_tab/segments_view.tsx
Outdated
Show resolved
Hide resolved
frontend/javascripts/oxalis/view/right-border-tabs/segments_tab/segments_view.tsx
Outdated
Show resolved
Hide resolved
frontend/javascripts/oxalis/view/right-border-tabs/segments_tab/segments_view.tsx
Outdated
Show resolved
Hide resolved
frontend/javascripts/oxalis/view/right-border-tabs/segments_tab/segments_view.tsx
Outdated
Show resolved
Hide resolved
…s/webknossos into segment-group-batch-actions
}; | ||
this.setState({ | ||
areSegmentsInGroupVisible: newSegmentsInGroupVisible, | ||
}); | ||
}; | ||
|
||
getSegmentsWithMissingLocation = (groupId: number): number[] => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd replace Location
with Position
here to keep it consistent with the somePosition
attribute.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great :) Code looks good to me and it works great, too 👍
Steps to test:
-- Right-click a group and set the color
-- Revert setting the color
-- Load meshes either ad-hoc or precomputed with a meshfile. If there is no meshfile, there should only be the option to load the meshes ad-hoc
-- Hide/show meshes. The text of the option should be adjusted to the current visibility
-- Download all meshes of the group. You should receive a zip with the according stl files.
Issues:
(Please delete unneeded items, merge only when none are left open)