Clipboard

[JakobDev]

I have seen, that there are now standard for a Clipboard, so I have develop a Standard. It is very easy to use and allow multiple types of informations like text or image.

[Lignum]

Hate to be a grammar nazi, but it's a document... Either way, this looks mostly alright, but I'm not entirely sure if this is really necessary. Though, perhaps you should mention what key combinations should be used for pasting/copying before programs decide on their own each.

[Lignum]

It is a table called "clipboard" in the shell environment.

Nouns shouldn't be capitalised. There's plenty other instances of this in the document, which I won't comment on to avoid clutter.

[Lignum]

Describes isn't even a noun... Don't capitalise anything unless it's at the beginning of a sentence or a proper noun (names of people or places, etc.).

[Lignum]

We already have MIME types, just refer to those, it's more flexible.

[oeed]

Definitely

[Lignum]

This being a global makes my soul scream, but there isn't really an alternative I can think of :/.

[Lignum]

"Information" should never be plural, it's just "Share information with other programs".

[oeed]

I can see this being useful. I think that maybe an API is the way to go over just a table, but I'm interested to hear what people think. One other thing you might want to add is whether is was cut or copy and if cut then clear it when pasted. I made an API for this for OneOS: https://github.com/oeed/OneOS/blob/master/System/APIs/Clipboard.lua

You do also have the issue of the real clipboard interfering.

[SquidDev]

I can see the use of a sane clipboard system, but a couple of thoughts:

• It should probably be a global API instead of just a table which one gets and sets. This way we can extend it with additional functionality without breaking code which depends on earlier standards.
• It would be nice to support multiple clipboard types at once. For instance, if someone copies something from an nft image, it could generate image/nft, image/nfp (just the background) and text/plain (just the text) clipboard entries, and programs only have to fetch the one they want, rather than converting on their end.
• I'd probably impose some requirement on the clipboard that the data structure added MUST be serialisable and immutable (so one cannot pass functions to the clipboard, and one should not modify the copied data structure).

I'm personally thinking of something like:

-- Get an entry of a particular type
function clipboard.get(name:string) end

-- Set the clipboard contents, where entries is a MIME type -> contents lookup
function clipboard.set(entries) end

-- Clear the clipboard
function clipboard.clear() end

If cut then clear it when pasted

Is this a mac-specific thing, as this seems rather weird to me - I'd expect to be able to paste a cut object multiple times.

You do also have the issue of the real clipboard interfering.

I guess you could check if the paste event is equal to the last string pasted and ignore it if so. Though that isn't really ideal. I don't think how programs should interface with the API is something which should be defined by the standard though.

[viluon]

Is this a mac-specific thing, as this seems rather weird to me - I'd expect to be able to paste a cut object multiple times.

I'm not sure if the behaviour @SquidDev seems to have in mind is a thing on certain systems, it does indeed sound more like a bug than a feature. However, what I think @oeed might have meant is the action a program has to perform e.g. when a file has been cut and then pasted. The file isn't moved anywhere from the directory it resides in until the user actually pastes it somewhere else - which might not even happen at all.

I'm not sure how the API should handle these cases...

[oeed]

Is this a mac-specific thing, as this seems rather weird to me - I'd expect to be able to paste a cut object multiple times.

Thinking about it, you're right, it's not universal. In some programs and situations (i.e. Excel, cutting files) it is the case though. I guess we'd want some way to tell the source that the cut occurred... maybe? Any ideas? It seems a little messy having to do that, but at the very least you'd expect cut files to be moved rather than copied. Perhaps we leave that up to the destination though.

It would be nice to support multiple clipboard types at once.

Definitely like that.

the data structure added MUST be serialisable and immutable

Agreed.