It would be good to have a way for the client program
to ask OpenGLEAN to ask the window system about the
current clipboard contents.
Some considerations:
* A system may have multiple clipboards (the Amiga
had a fixed number---10, I believe, corresponding
to the digits 0 through 9). Some way of retrieving
from more than just "the" (first/normal/main)
clipboard would be desirable.
* Clipboards may not be simple text. Again, the Amiga
offers an example: Amiga clips were in IFF format.
The encouraged approach was export selected data in
as many ways as made sense (so you might get a music
score (SMUS), audio (8SVX), and lyrics (FTXT), and
maybe even something like an album cover (ILBM) or
movie sequence (ANIM) in one clip. The Amiga
paradigm was to export the most expressive, natural
format first, followed more or less successively less
complete forms; readers were to take the first format
that they could handle and which made sense for the
reading application (a text editor would only get
FTXT; a paint package would likely only get an ILBM;
a music editor might try SMUS first, but support 8SVX
to import to an instrument).
So, reading the clipboard would involve at least saying
which clipboard you want to read, and possibly saying
what sort of data you're willing to handle. It might
be necessary to be able to ask after the names of the
clipboard(s), and the name of the default clipboard.
Doing this fully would be a substantial amount of
code. But if a stub implementation is used that
only supports text clipboards (but which has a
mechanism to request non-text types, and to request
a list of available formats ordered in decreasing
preference), then it could be fleshed out over time.
But a too-general version of this might do better in
its own library, with OS-specific data conversion
routines...
Also, of course, one wants to be able to export to the
clipboard.
Another reasonable alternative is to define an OpenGLEAN
API just for text clips. "Keep It Simple and Stupid".
Then there would be something of real utility, but
which could be supplanted by a more capable routine.
Perhaps a mechanism could be defined so that the client
could supply its own OS-specific clipboard handler?
(It really should be done in the event loop, I believe.
The usual way to write is merely to declare that you
have something for the clipboard, but not to actually
export to the clipboard until a reader declares their
interest. This would require some kind of event
mechanism and callback, unless OpenGLEAN immediately
generates the clip as soon as the client suggests that
it may have something of interest---such eager clip
generation may be too inefficient.)
