CraftOS-Standards icon indicating copy to clipboard operation
CraftOS-Standards copied to clipboard

Clipboard

Open JakobDev opened this issue 8 years ago • 4 comments

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.

JakobDev avatar Aug 05 '17 14:08 JakobDev

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.

oeed avatar Aug 05 '17 21:08 oeed

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.

SquidDev avatar Aug 06 '17 06:08 SquidDev

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...

viluon avatar Aug 06 '17 17:08 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.

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.

oeed avatar Aug 07 '17 06:08 oeed