Thanks for working on this.

On Sat Nov 28, 2020 at 3:17 AM CET, ~inkeliz wrote:

Currently, it seems a little bit harder to copy/paste inside some widget. Let's suppose some "custom Editor" (or even the Editor). If someone presses ctrl + v is expected to paste the text.

However, it can only be performed using the window.ReadClipboard and also listening to the main events (not the gtx.Events).

---

I'm proposing some change, which will match the design against the key.InputOp:

1. Create some ClipboardCopyOp and ClipboardPasteOp (or any other name), such as:

type ClipboardPasteOp struct {
Tag event.Tag
}

type ClipboardCopyOp struct {
Tag event.Tag

Why have a tag here?

Text string }

Let's match the method names: ReadClipboardOp and WriteClipboardOp.

1. You can receive the Event using the respective tag and also globally:

You can get the Clipboard information using:

for {
select {
case e := <-w.Events():
switch e := e.(type) {
case system.ClipboardEvent:
// Your code

Or, using the tag with layout.Context:

func(gtx layout.Context) layout.Dimensions {
for _, ev := range gtx.Queue.Events(&tag) {
///...
}
}

If multiples ClipboardCopyOp are sent in one frame, only the first must be processed.

For the other ops, the last one is the effective. Doesn't seem important in any case: clipboard writes should never happen within a single frame.

Elias

Why have a tag here?

So, consider the Tag for WriteClipboardOp to return some "error/success". I think it could happen in three cases:

1. If multiple WriteClipboard.
2. If the user doesn't allow write to the clipboard (maybe iOS/WASM?).
3. If the type of data isn't supported.*

*Today, I think Gio only supports texts/string. But, let's suppose that we add support for another kind of media (like Images: copy images to clipboard). If the platforms doesn't support the media type, will "return error" (via events).

Let's match the method names: ReadClipboardOp and WriteClipboardOp.

Sure.

On Sat Nov 28, 2020 at 20:23, ~inkeliz wrote:

Why have a tag here?

So, consider the Tag for WriteClipboardOp to return some "error/success". I think it could happen in three cases:

Reporting errors is only a good idea if the widget can react on it.

1. If multiple WriteClipboard.

Multiple concurrent writes doesn't seem like a problem; the clipboard may be overwritten at any time. Just choose one, say the last, and make that apply.

1. If the user doesn't allow write to the clipboard (maybe iOS/WASM?).

How would a widget react to this case? It seems to me the widget offers data, and the operating system declines it. Presumably the user is aware of the refusal.

1. If the type of data isn't supported.*

*Today, I think Gio only supports texts/string. But, let's suppose that we add support for another kind of media (like Images: copy images to clipboard). If the platforms doesn't support the media type, will "return error" (via events).

An error for unsupported data types seems to late. I can imagine a widget want to know whether a data type is supported before attempting a clipboard interaction. In other words, this case seems better suited for a platform query (say app.SupportedClipboardTypes).