-
Notifications
You must be signed in to change notification settings - Fork 171
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
Multiplayer shadows #4519
Multiplayer shadows #4519
Conversation
Job #9262: Bundle Size — 65.61MiB (+0.03%).
Warning Bundle contains 67 duplicate packages – View duplicate packages Bundle metrics
Bundle size by type
View job #9262 report View feat/multiplayer-shadows branch activity |
# Conflicts: # editor/liveblocks.config.ts # editor/src/components/canvas/multiplayer-cursors.tsx # editor/src/components/user-bar.tsx
@@ -263,6 +264,13 @@ export function absoluteResizeBoundingBoxStrategy( | |||
'starting-metadata', | |||
), | |||
queueTrueUpElement(childGroups.map(trueUpGroupElementChanged)), | |||
setActiveFrames([ |
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.
selectedElement, newFrame, ..... hmm these are also available in pushIntendedBoundsAndUpdateGroups
the action: 'resize' is the one piece that's missing
actually I wonder if the name pushIntendedBoundsAndUpdateGroups
could be changed to setStrategyIntent
, so it could store resize, target, frame (even originalFrame). it feels like if a strategy forgets to call pushIntendedBoundsAndUpdateGroups
that is a mistake. I wonder if setStrategyIntent
could be elevated to the level of StrategyApplicationResult
, meaning it would be impossible to return from the apply function without also setting what was the intent
<FollowingOverlay /> | ||
<MultiplayerShadows /> | ||
<MultiplayerCursors /> |
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.
file badly needs renaming
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.
or we have to move the other components to their own files
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.
it absolutely does, but I'd go with a separate PR to not pollute the diff
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!
Fix #4525
Problem:
With collaborative editing enabled, it's difficult to understand who is doing what on the screen.
Fix:
This PR introduces collaborative shadows in the editor.
When something is being interacted with via the mouse, a shadow outline is shown to the other participants in the room.
Screen.Recording.2023-11-21.at.2.21.37.PM.mov
Two shadows per element are shown:
move
,resize
, etc.)The colors of the outlines match the player colors.
The shadows are returned as either straight frames (where possible, to improve performance), or element paths and their frames get calculated in the multiplayer component when updating the presence.
As usual, this is a basic implementation with not much design work behind it.