Clipboard.txt -- How the Alltalk clipboard works

The kernel class Clipboard has only one instance.
This object handles messages from the event loop
associated with clipboard functions.

aClipboard.$request[state]
	This message is sent to the clipboard object
	when another app wants the clipboard data.

aClipboard.$release
	This message is sent to the clipboard object
	when another app takes over the clipboard.

By default, these are both null methods.
EditParagraph grabs these messages and implements
metaclass methods for #requestClip and #releaseClip
respectively.


RequestClip
	Create a file and write the internal clipboard
	data to the file. 
	
	Tell the kernel clipboard to read the file.

ReleaseClip
	Dispose of the EditParagrph clipboard data.


EditParagraph #cut, #copy

	Send the kernel clipboard the message #notify.
	This tells the system that we want to own the
	clipboard. When another app does a paste, it knows
	we are the ownerst to ask.

EditParagraph #paste
	If the local clipboard has data, we must be the
	owner of the clipboard, so in this case we just
	paste the data.
	If the local clipboard is empty, we have to ask
	someone else for the data.
	We send the message #write[aFile] to the kernel
	clipboard. This causes the kernel to ask the owner
	for the data and then write it to the designated
	file.
	EditParagraph reads the file and pastes the data.


For X Windows, we have some mismatched functions.
	The event methods for RequestClip and ReleaseClip
	fit pretty well.
	When we paste, the Clipboard.write function has to
	ask the other app for the data. In Unix this requires
	one or more event cycles to complete. In Windows,
	the call appears to be synchronous.

	The Unix version can simply do an internal busy
	loop on the Event queue until the other app 
	reponds. What if the other app dies in the
	middle of handling the request. How many event
	cycles should be looped?

