Open edemaine opened 3 years ago
I would like to paste screenshots into cocreate so that I can annotate them. These screenshots are typically of code, or parts of a gui. I use these in teaching.
@jkitchin Yep, that is issue #22.
This web page has an explanation, working code, and a live demo for how to gracefully copy/paste nontrivial data (with SVG as an example). I expected a Blob of type 'image/svg+xml' to be pasted, but that is not the case — that's currently unsupported. Instead, the clipboard should contain multiple representations of the same data. The raw svg appears with type 'text/plain', and a rendering of the svg is included as an 'image/png'.
(moved your message for you)
Yeah, I have some experience in Coauthor with defining a custom data type for internal representations of data. Oh, actually, looks like I only did so for dragging (also here), but I assume/hope the clipboard can behave similarly. This would let Cocreate -> Cocreate copy/paste work with the internal database representations.
Although the example app you linked doesn't fill a image/svg+xml
slot, I imagine it could, for apps that support it. Worth testing with programs like Inkscape and Illustrator.
For those following this issue, cut/copy/paste via Ctrl/Command-X/C/V now works quite well. In particular, you can now copy objects from one page to another, or even between boards! You can also paste links to images and they'll get embedded (part of #144), or paste text and it'll turn into a text object (part of #142).
@edemaine I'm not quite sure what I might be doing wrong, but I cannot seem to copy text from one board to the next using crtrl C then V. I can't even copy/paste text within the same board. Any advice?
What server, operating system, and browser are you using? For CSAIL, Windows, Chrome it works well.
Gather.Town, Windows, and Chrome. I think the issue might be with Gather, I'm just not quite sure how to fix it.
Yeah, Gather.Town is running an older version of Cocreate, which doesn't have this feature. We need to wait until they update...
I've started implementing
Should the objects be offset to be visible if they aren't?
in the commit above; here are some conceptual questions copied from the commit message:
edemaine#94 suggests this should only apply if the original location falls outside the viewport. Is it ever desirable that pasted content appears exactly at its original location? If so, should the test be "original location entirely on screen" or "original location partially on screen"?
It would be nice if pasted content could appear at the mouse instead (a la Inkscape), but unfortunately it seems like there's no way to get the cursor position without a mouse event, and doing something like storing the position of the most recent mouse event seems messy.
Should the paste offset always be grid-snapped even if snapping is disabled? This is probably barely noticeable when unwanted but greatly annoyance-reducing when wanted.
I think I'm now convinced that Ctrl-V should paste in the center of the view, or mouse cursor if it's been seen since the last pointerleave
event. (This matches Inkscape behavior. Illustrator always pastes at center of view.)
Ctrl-Alt-V (Inkscape's shortcut) or Ctrl-Shift-V could be the new way to access "paste in place". It's useful e.g. when copying things into previously duplicated pages. It will only work for content copied from the current Cocreate window, but that's probably all we need.
Should probably only round when grid snapping is off.
This would be particularly useful for pasting across boards or pages.
paste
event) detects object contents and recreates (and selects) objects on current page