New Toolbar

[philippotto]

This PR:

• changes the tool text labels to tool icons
• adds dedicated tool modes for the fill-tool and the cell picker
• adds overwrite-mode buttons (to switch between overwrite-all vs overwrite-only-active)
• adds dynamic updating of the toolbar when pressing modifiers
  • e.g., when pressing shift, the active tool is changed to the cell-picker tool
  • e.g., when being in the move (skeleton) tool, pressing a modifier will open a tooltip which explains the current behavior
• ctrl+right click won't center the active node anymore (ctrl+right click is used to create a new node without activating it; in my opinion this should not re-center the current node which is why I changed/fixed this)
• middle-click-drag moves the plane (similar to alt+mousemove) (fixes middle-click plus drag for move during brush mode? #4823)
• fixed antd border styling when a switch-button was hovered or activated (some borders were missing before)
• during testing how often the new toolbar re-renders, I noticed that the SaveButton rerendered on every position change. Therefore, I improved the SaveButton component so that it doesn't re-render that often:
  • the current timestamp and the lastSavedTimestamp is computed/accessed ad hoc instead of writing it into the state
  • the progress percentage (which is null most of the time) is passed as a prop instead of passing the progressInfo which changes on every movement
    • maybe we should consider to not persist each movement as an updateTracing action. the save_saga will compact this later, but before that the store is updated with a very high frequency. it could be more performant to throttle this as early as possible. just some food for thought...

URL of deployed dev instance (used for testing):

• https://newtoolbar.webknossos.xyz

Steps to test:

• test all tools and play around with the modifiers to see whether everything behaves as expected

Issues:

• fixes Rework skeleton and volume toolbar #4787

---

• Updated (unreleased) changelog
• Updated (unreleased) migration guide if applicable
• Updated documentation if applicable
• Adapted wk-connect if datastore API changes
• Needs datastore update after deployment
• Ready for review

[daniel-wer]

Wow, this PR is so beautiful, I'd like to print it out and put in on a poster 🤩
It's great how you decoupled the overwrite behavior from the active tool and made the code much easier in many places. Also the structured use of hooks in the volume_actions_view makes it very easy to reason about the code in what is actually a fairly complex component.
Everything is so much more discoverable now!

I only noted a couple of clarifying questions and suggestions. During testing everything worked exactly as described, except for these two small issues:

• Small UI glitch (blue vertical bar) when hovering over the disabled volume tool buttons when merger mode is active (see screenshot).
  
• If a cell is active (blue, for example) and then a mapping is activated which changes the cell id (and color to red for example), the dot in the "Create new cell ID" button remains blue and the tooltip contains the old unmapped cell ID. When annotating, the new cell ID and red color is correctly used.

[daniel-wer]

As this is a breaking change (line 28), we should make sure to communicate it properly during release (and highlight volume undo again, maybe :))

[philippotto]

Thank you for your kind feedback :) I think, I covered the crucial aspects now.

Regarding the "breaking change", I'm not 100% sure whether it's necessary to communicate this. I'm afraid it will be difficult to explain/grasp and the potential risk impact is not very high (as there is the undo-feature). We could communicate it to the lab managers, but I'd assume that they won't propagate the new information to all users, as it's not super important in the end (?). What do you think?

[daniel-wer]

Very nice, everything worked well during my renewed testing round 👍 LGTM

Regarding the "breaking change", I'm not 100% sure whether it's necessary to communicate this. I'm afraid it will be difficult to explain/grasp and the potential risk impact is not very high (as there is the undo-feature). We could communicate it to the lab managers, but I'd assume that they won't propagate the new information to all users, as it's not super important in the end (?). What do you think?

I don't have a strong opinion on this. You're right that with the volume undo working, no real harm can be done 👍