AffDes+AffPhoto-ALLVersions incl.Betas:Copy to clipboard

[catlover]

Sequence of actions:

>Open AffDes : File >Open >Edit >Select object>Copy
>Quit AffDes,
>Open AffPhoto >File New >Edit >Paste.  BUT :
Paste is not possible : =Greyed out,  File "New from Clipboard" is greyed out as well.
Both Paste methods are however available when both apps remain open.
This also happens with the Beta Version of both Apps.

Does this mean that upon quitting the app the clipboard contents are wiped ?
I always thought that the clipboard contents remain always available, until overwritten by another copied item.
Can someone shed some light on this please ?

Thanks as always,

C.L.
 

[Callum]

Hi Catlover,

This was logged when you reported it last here: 

It was closed by our developers as by design I will try and find out a little more information regarding this for you. I can see why we would clear clipboard contents with our own objects on the clipboard but it also does this with just standard text so I can't really see how this isn't a bug.

Thanks

Callum

 

[carl123]

9 minutes ago, Callum said:

I can see why we would clear clipboard contents with our own objects on the clipboard

I cant.

When pasting from one Affinity application to another, if short on resources, (low spec PC) you may want to close the copied from application before firing up the other one and doing the pasting

[Callum]

3 minutes ago, carl123 said:

I cant.

When pasting from one Affinity application to another, if short on resources, (low spec PC) you may want to close the copied from application before firing up the other one and doing the pasting

But not all applications support our objects so it makes more sense to me for the clipboard to be wiped when closing the app than not. It's not ideal granted but I'd say it still makes more sense to wipe the clipboard.

Thanks

Callum

[carl123]

It still makes no sense to me, if I copy from an Affinity app, leave the app open and try to paste into a non Affinity app that does not support your objects then nothing should happen so why wipe the clipboard when the contents are still viable for other Affinity apps.

[Callum]

4 minutes ago, carl123 said:

It still makes no sense to me, if I copy from an Affinity app, leave the app open and try to paste into a non Affinity app that does not support your objects then nothing should happen so why wipe the clipboard when the contents are still viable for other Affinity apps.

I'm not a developer so I can't really give any solid information regarding this other than my own opinion. 

[carl123]

Which only leaves us with conspiracy theories.

[Alfred]

5 minutes ago, carl123 said:

It still makes no sense to me

Me too neither! It should be left up to the receiving application to deal with the contents of the clipboard.

[Patrick Connor]

As I understand it, when you press "Copy" affinity declare a number of potential formats onto the clipboard. The Pasting application decides what it wants to paste. If it is one of our applications then we would choose our own internal format over one of the lesser offerings (image, text, RTF, SVG or whatever we choose to support as well as our own internal format) "Copying" does not necessarily mean that we put the data onto the clipboard when Copy is pressed, there and then . Importantly it means that the software understands how to paste if asked. Text may be put onto the clipboard immediately, but many other optional formats are only actually added to the clipboard IF pasted.

The receiving application pastes the format it most likes. HOWEVER when paste is pressed that format is requested off the clipboard. For some applications like ours, that paste action is the first time the copied item is actually rendered onto the clipboard. Delayed rendering makes the initial "Copy" faster, because it does not use up loads of memory making clipboard items in all the other formats that are never going to be pasted outside of the Affinity application, which would have wasted memory and time for no purpose. However once "Paste" is requested in one of those non-Affinity formats the source needs to be available. SO to "leave objects on clipboard" when the application is closed requires the copied object to still be available and to render it onto the clipboard. That would slow down all "document close" actions and increase the memory footprint. If the option exists the render/draw of ALL AVAILABLE FORMATS (excluding Affinity's own internal format, as those objects have well and truly gone) on the clipboard has to be done there and then, just in case another application subsequently "Pastes" that format later. That draw of all supported clipboard formats wastes time and memory (and didn't work reliably).

To summarize, the option either slows down "Copy" (don't use delay render) or would slow down "File Close" (or application shutdown). Considering how many people need the clipboard contents after the application closes that is not IMHO worth it.

[carl123]

Similar to the conspiracy theory I was thinking but I accept your answer, so thanks for the clarification.

It's good to share this sort of stuff

[catlover]

I seem to have poked a hornet's nest here.

Sorry, guys, it was only meant to be a simple question : why can I not paste an object created in one Aff app into another Aff app .

Patrick's answer makes sense to me, thanks !

[v_kyr]

You can try some addon clipboard manager tools, there are a bunch of those for different OS. Some of these tools keep a history and thus do store all that you have copied or cut in the past, some also offer sort of a customizable snipped management ... and so on. - (Just two Mac OS related examples here and here).

See also related:  How to access and manage clipboard history on mac

 

[Patrick Connor]

No matter what clipboard manager you use the, if the source Affinity application has closed, the Affinity objects themselves WILL HAVE GONE so the best you will get is paste of a lesser format. Clipboard managers effectively request a paste immediately, slowing the source application down to no real effect.AFAIK it can not force a copy of our own internal format, and even if it did that would fail if the source application closes after a clipboard manager does an effective "forced" paste.

[v_kyr]

Depends on how it has been implemented for certain tasks here (see for example the OSX Pasteboard) and to quote from that ...

Quote

...Pasteboards can be public or private to one or more applications. Public pasteboards are system provided and are available to all applications. All pasteboards, public and private, must have a unique name. Both platforms have general-purpose pasteboards and pasteboards used in search operations. In iOS, these pasteboards are named UIPasteboardNameGeneral and UIPasteboardNameFind; in OS X, they are named NSGeneralPboard and NSFindPboard. OS X has additional named system pasteboards for rulers, fonts, and drag-and-drop operations. An application on either platform typically uses one of the system pasteboards, but may create a private pasteboard under a unique name; for example, it might create a private pasteboard to share data with a “sibling” application that was created by the same software vendor....

Further there is an Affinity AD option, though I never tried that option, so I don't know if it's doing then what I would assume here ...

Quote

Choose whether to create SVGs when copying objects for better cross-platform interaction.

... I can imagine that this then copies probably SVG code as text or the like.

[R C-R]

3 hours ago, v_kyr said:

Further there is an Affinity AD option, though I never tried that option, so I don't know if it's doing then what I would assume here ...

FWIW, in English, the option is labeled "Copy items as SVG" & it does exactly that -- puts an XML formatted text version of whatever is copied in Affinity onto the clipboard. So for example, if you select both a text & pixel layer in Affinity & copy it with that option enabled, the clipboard is filled with text beginning with a document type declaration something like this:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">

In this case, there will be one or more <text> items plus an <image ...> item that can require many megabytes of text depending on the size of the pixel layer. You can paste this into any app that accepts text objects, but as you might expect, what you get depends on the app. 

For example, without the 'copy as SVG' option enabled, TextEdit will treat the clipboard contents as a flat image, so if a TextEdit document is using the Rich Text format, the flat image will be pasted; if it is using the Plain text format, nothing is pasted. With or without the option enabled, Preview app pastes a flat image as a PDF document. Without the option enabled, Nisus Writer Pro also pastes a flat image; with it enabled you get a link named "Clipboard" that if clicked opens an Affinity document named "Clipboard.svg" with the svg layer structure preserved. Interestingly, even if no Affinity app is open, this still works! 

I haven't tested this with any other app but since quitting the Affinity app clears the clipboard, the bottom line is copying must be done with the Affinity app open (even if no document remains open after the copy) or there won't be anything to paste into any other app. Considering that it is possible to copy dozens or hundreds of pixel & image layers to the clipboard in Affinity, which could require huge amounts of /private/var/folders file storage space to retain independently of the Affinity app, this seems like a sensible choice to me.

[v_kyr]

13 minutes ago, R C-R said:

Without the option enabled, Nisus Writer Pro also pastes a flat image; with it enabled you get a link named "Clipboard" that if clicked opens an Affinity document named "Clipboard.svg" with the svg layer structure preserved. Interestingly, even if no Affinity app is open, this still works! 

That's what I somehow assumed it would behave then, though without passing over a temp file link and instead the textual contents of that "Clipboard.svg" file. However, most other tools can deal with copy/paste of text and thus the one or other can make use out of that.

21 minutes ago, R C-R said:

I haven't tested this with any other app but since quitting the Affinity app clears the clipboard, the bottom line is copying must be done with the Affinity app open (even if no document remains open after the copy) or there won't be anything to paste into any other app.

There are clipboard tools which claim to hook inbetween that copy/paste state and fetch at least the text, some tools also claim to support more than just text, but I didn't tested that so far. Further it's more interesting to exchange via pasteboard interaction then formats which are supported between/among apps.

OT: as somebody who also programs a lot, it would be interesting for AD on Macs to have the ability to copy as an explicite reusable "core image" code representation too, like the Graphic app does offer here.

[R C-R]

1 hour ago, v_kyr said:

That's what I somehow assumed it would behave then, though without passing over a temp file link and instead the textual contents of that "Clipboard.svg" file. However, most other tools can deal with copy/paste of text and thus the one or other can make use out of that.

From what I can tell from my limited testing, some apps accept svg formatted clipboard text 'as is' as plain text but others like Nisus don't. In BBEdit, File >  New > Text Document, followed by Edit > Paste, or New > Text Document > (with clipboard) opens the fully XML formatted svg text like TextEdit does in RTF mode, but this can create hugh file sizes if saved, depending on what was copied to the clipboard in Affinity. Nisus creates a very compact file with the reference to the "Clipboard.svg" file in the private/var/ folder, but that is (I think) dependent on the full "Clipboard.svg" file remaining in that folder, which (surprisingly?) is not always immediately deleted when the Affinity app is quit.

I don't know what to make of that. 

[v_kyr]

Interesting! - BTW, AFAI can see a nice side effect of SVG related copy/paste here is, that the SVG code is then also much better formated.

In the above shown screenshot the top underlayed Sublime Text window shows how AD exported SVG code looks, the bottom one shows how it get's instead formated via SVG copy/past of the clipboard. I also checked with Textmate and saw the same behavior there. This way SVG code is much better formated and readable, when exchanged via copy/paste.