This is the mail archive of the
mailing list for the Cygwin XFree86 project.
RE: [ANNOUNCEMENT] xwinclip Test 01 (Cygwin/XFree86 andWindowsclipboard integration)
- To: Harold Hunt <huntharo at msu dot edu>
- Subject: RE: [ANNOUNCEMENT] xwinclip Test 01 (Cygwin/XFree86 andWindowsclipboard integration)
- From: Robert Collins <robert dot collins at itdomain dot com dot au>
- Date: 04 Sep 2001 14:29:28 +1000
- Cc: cygx <cygwin-xfree at cygwin dot com>
- References: <NHEELHJHHFKPMAEAFMFCMEBBCJAA.email@example.com>
On 04 Sep 2001 00:00:19 -0400, Harold Hunt wrote:
> I couldn't find any documentation on /dev/clipboard
my bad. Mind you the source is quite easy to read.
> and I don't understand
> the mechanism. I looked at the source code, but I still don't understand
> what is going on.
> Here's what I mean:
> 1) When reading from the Windows clipboard directly I list the type of
> formats available (pixmap, text, file, etc.) for the data with
> EnumClipboardFormats, and I select the format I want by passing it to
> GetClipboardData. I have no idea how to get the format of the data waiting
> on /dev/clipboard.
It's an unformatted bitstream. We haven't needed to give unix-style
programs format meta data so far. That could easily be allowed via an
> 2) When writing to the Windows clipboard, I specify the format of the data
> being written by passing the format type to SetClipboardData. Once again, I
> have no idea how to specify the format of data being written to
Again, the unix approach of 'its a file' applies. We write everything we
recieve to the clipboard twice. Once in CYGWIN_NATIVE_CLIPBOARD format,
which preserves binary data - ie .wav or .exe files, and once in
(current_codepage == ansi_cp ? CF_TEXT : CF_OEMTEXT) format to allow
windows applications to copy the data.
> 3) I have no idea when conversions from UNIX to DOS text occur with
The filemode that /dev/clipboard is opened with does this automagically
before it hits the clipboard code.
> I guess, in short, it is easier, so far, for me to just read the MSDN
> Library and use the clipboard API functions directly. I find that I rarely
> get work done when I don't have a pile of documentation and/or operating
> specifications to look at.
Sure - I understand that myself :}.
> However, you know a lot about the Windows clipboard API, so I'd appreciate
> any direct or indirect contributions you have to make (including some specs
> on how /dev/clipboard works).
Ok, some notes - semi random brain dump :}.
Formats and why I did'nt code for them:
With /dev/clipboard, and no cygwin daemon (Corinna, this is another item
for the dameon :}) we cannot do onrequest-format conversion with
/dev/clipboard because the process writing to /dev/clipboard terminates.
This means that all format information has to be applied to the windows
clipboard in one hit. (It would be more efficient to simply tell windows
we have data, and can support _any_ format, and then wait for a request,
which we can satisfy with the optimal clipboard format.) So supporting
multiple formats means a separate copy of the data is written to the
windows clipboard at write time. Ouch.
For now, because of this we create only two clipboard data instances: 1)
with a CYGWIN_NATIVE_CLIPBOARD only format, to allow us to read the
exact data written to the clipboard back again. 2) with a TEXT format to
allow windows applications to get the data.
With a daemon, we can buffer the local data, register all the
appropriate FORMATS we can support via translations and use an ioctl to
let cygwin apps tell us what the data really is. (ie ioctl (fd,
cyg_clip_format, "text/html") ).
writing to /dev/clipboard
Because we don't know how much will be written, we cannot use a fixed
buffer, and because the writing process may trickle data in we
accumulate the written data, and at the end of each write() copy the
current content to the windows clipboard (once in each format). If a
seek occurs, we rewind the buffer.
reading from /dev/clipboard
We try to read in CYGWIN_NATIVE_CLIPBOARD, and then in the appropriate
TEXT format. This allows us to copy binary data through the clipboard.
We allow seek()ing through the read buffer.
Future work possible/thought of:
* format metadata. Needs a daemon to be practical. _very_ useful. iotcls
are needed - should be copied from linux/X something that has similar
behaviour. (I couldn't see anything obvious on linux :[).
* on-demand formatting - needed for proper format metadata operation.
Requires cygwin daemon (like your clipboard process). Would be no more
memory efficient than current implementation, but much more flexible.
X11 clipboard interface:
Basically /dev/clipboard and the X11 clipboard have the same job to do.
Provide a unix-convention interface to the windows clipboard, in both
directions. I suspect that the X11 clipboard interface is quote similar
to the windows clipboard. What I would suggest doing is:
1) Make the X11 clipboard functions a wrapper around /dev/clipboard.
2) Add functionality to /dev/clipboard to minimize the amount of code
needed in the X11 clipboard. (ie the ioctls, daemon persistence etc).
Doing this would minimize the duplication of effort and code. It would
also mean that multiple X servers would share a clipboard - is that a
good thing or a bad thing? (I know that all the linux virtual consoles
share a clipboard)...
However, as there is no cygwin daemon now, and the discussion to set the
API etc is just underway you can't do 2) yet and I don't want to hold up
your work... so ...
Howabout this: treat your X11 clipboard app as a testing base for the
eventual code needed by the cygwin daemon. Ie write your code with the
intent that it is generic, not X specific, that the X11 stuff is a layer
above it. The lower layer registers for delayed format creation,
supports setting the content type and translating appropriately and so
forth. Then when the cygwin daemon starts to shape up, the lower layer
can get moved to the daemon, and upper layer is whats in the X server
code providing the X11 clipboard interface.
Likewise, /dev/clipboard will become a basically empty wrapper around
the daemon functions.