Re: /dev/clipboard

["Robert Collins" <robert dot collins at itdomain dot com dot au>]

---- Original Message -----
From: "Charles S. Wilson" <cwilson@ece.gatech.edu>
To: <cygwin-developers@sources.redhat.com>
Cc: <robert.collins@itdomain.com.au>
Sent: Friday, March 23, 2001 6:27 AM
Subject: Re: /dev/clipboard


> Replies to two messages, below:
>
> > Subject: /dev/clipboard
> > Date: Thu, 22 Mar 2001 11:04:28 +1100
> > From: "Robert Collins" <robert.collins@itdomain.com.au>
> > That's my only quandary at the moment.
>
> Errmmm...linux?  /dev/clipboard documentation?  What's that?...

:]

> No, I just used msdn's docs on the windows clipboard.  Given the
> firestorm of requests for the feature six months ago, I figured that
if
> I made a stab at partial support, hordes of users would suddenly start
> contributing patches to "enable write support" and "make it more like
> UWin's /dev/clipboard" and "do it the way Linux does"...
>
> Ha.  Ha Ha.  Ha Ha Ha.

I'm amazed how easy the behind the scenes stuff is for cygwin.... Kudos
to the core team! I'd never have tackled the clipboard if pthreading
hadn't turned out to be absolutely straight forward systems programming
:]

> But I'm am glad that you are picking up the project.  Thanks for your
> work and contributions to this part of cygwin's functionality.

No probs...

> > Subject: /dev/clipboard
> > Date: Thu, 22 Mar 2001 16:41:52 +1100
> > From: "Robert Collins" <robert.collins@itdomain.com.au>
> > To: <cygwin-developers@cygwin.com>
> >
> > Success! I have a fully read/write /dev/clipboard that doesn't alter
the
> > data at all(note 1).
> > * seek() is implemented as rewind() for now.
> > * Competing process's should be atomic for clipboard access.
> > * Data written is available as soon as it is written
> > * Binary (non-text data types) data crashes cygwin on read (you
can't
> > have everything :]).
>
> Cool.  (Can we, as a temporary fix, have cygwin check for
> 'CF_TEXT|OEMTEXT' and return NULL when a text version of clipboard
> contents does not exist?)

A full, final fix is in place in the patch I submitted last night.

> > Todo:
> > * Handle the core windows datatypes (ie translate dropped files into
a
> > list of cygwin paths, DIBS into binary data..)
Still toto
> > * Handle binary data (this involves registering a custom CYGWIN
> > clipboard format that is self-terminating. Unfortuneatly this means
that
> > windows apps won't read the clipboard unless we handle delayed
> > rendering.. or always put a CF_TEXT|OEMTEXT version on the clipboard
as
> > well.).
Done. We put a custom format, and a CF_TEXT|OEMTEXT on the clipboard
every time.
> > * Allow arbitrary seek() calls.
Still todo:
> > * Allow fstat() to return the current data size of the clipboard.
Still todo: depends on the next two.
> > * Allow ls /dev to show clipboard
I'm seeking guidance and inspiration here (other than debugging ls!.)
> > * Allow ls / to show /dev
I'm seeking guidance and inspiration here (other than debugging ls!.)
> >
> > Wishlist:
> > * Someone else to find a testkit for /dev/clipboard.
> > * Vi/Xterm etc etc etc to all support /dev/clipboard automagically.
> >
>
> [ Question for which I have no answer snipped]
>
> > I'm happy to send in a patch now, or get a few of the TODO's done
> > first... any other requests anyone?
>
> Other than a short-term workaround to prevent cygwin from crashing,
send
> in the patch now.  Partial support now is better than complete support
> that springs fully formed like Minerva from the head of Zeus -- months
> or years from now.

Yup :]

> > (note 1: ascii 00's are lost currently (Binary data), but otherwise,
cat
> > foo > /dev/clipboard && cat /dev/clipboard > foo2 && diff foo foo2
shows
> > no differences.).
>
> Even if foo is much bigger than cat's built-in buffer (4k, I believe)
?

administrator@LIFELESSWKS /usr/src
$ ls -l zlib.tar.gz
-rwxrwxrwx   1 544      None       757760 Jan 14 23:31 zlib.tar.gz

administrator@LIFELESSWKS /usr/src
$ cat zlib.tar.gz > /dev/clipboard

administrator@LIFELESSWKS /usr/src
$ cat /dev/clipboard > comp.tar.gz

administrator@LIFELESSWKS /usr/src
$ diff comp.tar.gz zlib.tar.gz

:] The problem that existed before was that you only satisfied the first
request - I'm allowing sequential reads ||sequential writes, so cat
(which uses a 1024 bytes block size) works fine. dd was the best test
toool I found for isolating bugs.

Rob

>
> --Chuck
>