-
Notifications
You must be signed in to change notification settings - Fork 24
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
Add toggle color layer visibility button #3943
Conversation
@@ -68,7 +68,21 @@ | |||
"properties": { | |||
"name": { "type": "string" }, | |||
"category": { "enum": ["color", "segmentation"] }, | |||
"elementClass": { "enum": ["uint8", "uint16", "uint24", "uint32", "uint64", "float,", "double", "int8", "int16", "int32", "int64"] } | |||
"elementClass": { |
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.
my ide beautifies code again 🤔
As this is accepted by prettier I suggest to keep it this way.
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.
Hmm, in the long run, this can be quite cumbersome. This is especially prone to merge conflicts. Can you please disable any IDE auto-formatting which differs from prettiers behavior?
@@ -39,8 +39,8 @@ import constants, { | |||
} from "oxalis/constants"; | |||
import messages, { settings } from "messages"; | |||
|
|||
const Panel = Collapse.Panel; | |||
const Option = Select.Option; | |||
const { Panel } = Collapse; |
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 done by my ide
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.
Nice work :)
I have a few thoughts about this feature:
- Could you add a yellow/orange
warning
icon with a tooltip next to the "Color Layers" header if any of the color layers is disabled? I'm afraid of users disabling layers by accident or forgetting about it. - Should we think about this more in terms of "Enabling/Disabling" the layer? I would, for example, disable all the layer controls of one layer (brightness, contrast etc.) of one layer if it is disabled. Also in the future we'll likely not load data for disabled layers as a performance optimization - the naming would make this clearer imo. Additionally, users would be less confused why there is an opacity slider and also a visibility toggle if the toggle would have the enable/disable connotation. What do you think? (Also @philippotto )
- Lastly, @georgwiese could you try this feature on the linked test branch? Does this work for you, any feedback? :)
frontend/javascripts/oxalis/view/settings/dataset_settings_view.js
Outdated
Show resolved
Hide resolved
frontend/javascripts/oxalis/view/settings/dataset_settings_view.js
Outdated
Show resolved
Hide resolved
frontend/javascripts/oxalis/view/settings/dataset_settings_view.js
Outdated
Show resolved
Hide resolved
Works for me! Cool! I'd still need that the layers are not blended additively but with alpha blending, but gues that's another issue. |
@daniel-wer I applied all your feedback. Could you please review my changes again? 🙂 |
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.
Sweet, I added some recommendations, but afterwards this should be ready to merge :)
This PR adds a button to each color layer that enables/disables the layer's visibility. This is done by adding the property
isVisible
to color layer configurations. => changed toisDisabled
.URL of deployed dev instance (used for testing):
Steps to test:
Issues:
[ ] Updated migration guide if applicable[ ] Adapted wk-connect if datastore API changes[ ] Needs datastore update after deployment