Comment 117 for bug 11334

I say it should be fixed in the X.org layer. Otherwise you have DE's reinventing the wheel here when they shouldn't have to. Here is how it should be working:

1. Copy or cut something into the clipboard.
2. It copies directly into ram without needing the original app open after it's done.
3. If it is too large, put a message that it is unable to copy that large amount. It can test this by estimating how much memory it is going to take up.
4. When you close that app it stays there.
5. An app can set a flag that checks if its still in memory when exiting, then upon closing the app, the Xorg layer of the clipboard will warn the user that the app is leaving this in memory and asks the user if they want to clear it upon exiting the app. It can pause the exiting of the app to do this. This way we don't have to have a hard coded value. It is up to the app to correctly set this flag such as audio/video/image editing apps.
6. When the user has made up their mind of what they want to do, then the app finishes exiting.

The API needs the following features:

1. Estimation of how large the object is going to be in memory so that it doesn't take up all the users memory. A good percentage I think is 90% here.
2. A flag that is set that when the app has exited, X.org is to ask the user if they want to keep the clipboard contents in memory or delete them. When the user has answered this, then the app in question is allowed to continue exiting.
3. Confirmation that the object has been copied into the clipboard or if it hasn't, the reason why which goes to point 1.
4. When you cut an object, only delete the original if you paste the new object.
5. Object type that is copied into the clipboard. This is so that we can identify the object that is in clipboard and possibly identify which app would be appropriate to be able to use it in.

To expand on this object type, we can have 5 basic types:

1. Text
2. Raw Audio
3. Raw Video
4. Raw Images
5. A file

Just an idea here, what do the rest of you think?