feat: add comment view (for workspace comments, and block comments for partners) #7914
Conversation
BeksOmega
force-pushed
the
feat/comment-view
branch
from
f711728
to
ba9b7da
Compare
|
|
||
| // TODO: Remove this comment before merging. | ||
| // I think we want comments to exist on the same layer as blocks. | ||
| workspace.getLayerManager()?.append(this, layers.BLOCK); |
There was a problem hiding this comment.
The disadvantage of being on the same layer as blocks is that a block can go over the comment and look like it's inside it. That's a bigger issue with mutators bubbles, since they always hold blocks. I'm neutral on which one we should do for comments.
There was a problem hiding this comment.
There is also a weird thing where when we deserialize, the comments will be deserialized after blocks, so they'll always end up on top after load even if they were behind blocks before.
| svgRoot, | ||
| ); | ||
| // TODO: Before merging, does this mean to override an individual image, | ||
| // folks need to replace the whole media folder? |
There was a problem hiding this comment.
Do you have thoughts on this @rachel-fenichel ?
There was a problem hiding this comment.
I don't know. Is replacing those images an immediate need, or a theoretical one?
There was a problem hiding this comment.
It's a need for spork blocks. For MakeCode we can just include their image in core.
There was a problem hiding this comment.
@maribethb as well.
There was a problem hiding this comment.
Yeah, they do, but tbh they probably should anyway because the default one links to one hosted on app engine. I don't see this as being a concern, it's how the rest of media assets work. If we wanted to refactor that in the future that's a different discussion and shouldn't be folded into this work imo
There was a problem hiding this comment.
Ok I'll dig into what MakeCode is currently doing and chat with them if it seems like it might be a problem. Since we've been holding v11 until we can have stuff ready for MakeCode, I want to make sure it actually is ready, and they're not going to have to wait for a v12.
There was a problem hiding this comment.
What kind of problems are you thinking about? The media directory is already configurable via options, and they can copy the assets they want to keep the same into their own hosting solution (which is what we currently recommend, though not that loudly). I feel like I'm missing something here if you're worried about something needing a v12.
There was a problem hiding this comment.
You're right I don't think this would need a v12. If anything I would just make it possible to configure the assets individually (which would be a feat not breaking). Based on some investigation it looks like they're already hosting everything themselves so it shouldn't be an issue. I just want to make sure we have everything pinned down so we can actually say MakeCode has been migrated.
The basics
The details
Resolves
Fixes #7905
Proposed Changes
Adds a comment view class which will later be used to
Reason for Changes
Test Coverage
Manually tested:
Documentation
There will need to be lots of docs later.
Additional Information
Hopefully this is broken up in a way that's easy to review commit-wise 🤞 I do split some methods out into sub-procedures in later commits, but I think that's the only thing that majorly changes between earlier commits and later ones.