https://bz.apache.org/ooo/show_bug.cgi?id=128612
Peter <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #15 from Peter <[email protected]> --- Hi Damjan, https://www.x.org/releases/X11R7.7/doc/xorg-docs/icccm/icccm.html i quote > The CLIPBOARD Selection > > The selection named by the atom CLIPBOARD is used to hold data that is being > transferred between clients, that is, data that usually is being cut and then > pasted or copied and then pasted. Whenever a client wants to transfer data to > the clipboard: > > It should assert ownership of the CLIPBOARD. > > If it succeeds in acquiring ownership, it should be prepared to respond > to a request for the contents of the CLIPBOARD in the usual way (retaining > the data to be able to return it). The request may be generated by the > clipboard client described below. > > If it fails to acquire ownership, a cutting client should not actually > perform the cut or provide feedback that would suggest that it has actually > transferred data to the clipboard. > > The owner should repeat this process whenever the data to be transferred > would change. > > Clients wanting to paste data from the clipboard should request the contents > of the CLIPBOARD selection in the usual way. > Except while a client is actually deleting or copying data, the owner of the > CLIPBOARD selection may be a single, special client implemented for the > purpose. This client maintains the content of the clipboard up-to-date and > responds to requests for data from the clipboard as follows: > > It should assert ownership of the CLIPBOARD selection and reassert it any > time the clipboard data changes. > > If it loses the selection (because another client has some new data for > the clipboard), it should: > > Obtain the contents of the selection from the new owner by using the > timestamp in the SelectionClear event. > > Attempt to reassert ownership of the CLIPBOARD selection by using the > same timestamp. > > Restart the process using a newly acquired timestamp if this attempt > fails. This timestamp should be obtained by asking the current owner of the > CLIPBOARD selection to convert it to a TIMESTAMP. If this conversion is > refused or if the same timestamp is received twice, the clipboard client > should acquire a fresh timestamp in the usual way (for example by a > zero-length append to a property). > > It should respond to requests for the CLIPBOARD contents in the usual > way. > A special CLIPBOARD client is not necessary. The protocol used by the cutting > client and the pasting client is the same whether the CLIPBOARD client is > running or not. The reasons for running the special client include: > > Stability - If the cutting client were to crash or terminate, the > clipboard value would still be available. > > Feedback - The clipboard client can display the contents of the clipboard. > > Simplicity - A client deleting data does not have to retain it for so > long, thus reducing the chance of race conditions causing problems. > The reasons not to run the clipboard client include: > > Performance - Data is transferred only if it is actually required (that > is, when some client actually wants the data). > > Flexibility - The clipboard data may be available as more than one > target. maybe we should think about the clipboard code a bit. Tracking events and history seem to have a time based component. With all the managers around which store history, there seem also to be issues. at least for this issue we could check timestamps and maybe check if the content has changed? -- You are receiving this mail because: You are the assignee for the issue.
