Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Message-ID: <3ABA521C.52B04BED@ece.gatech.edu>
Date: Thu, 22 Mar 2001 14:27:24 -0500
From: "Charles S. Wilson" <cwilson AT ece DOT gatech DOT edu>
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: cygwin-developers AT sources DOT redhat DOT com
CC: robert DOT collins AT itdomain DOT com DOT au
Subject: Re: /dev/clipboard
References: <985277679 DOT 11463 DOT ezmlm AT sources DOT redhat DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Replies to two messages, below:

> Subject: /dev/clipboard
> Date: Thu, 22 Mar 2001 11:04:28 +1100
> From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
> To: <cygwin-developers AT cygwin DOT com>
> 
> After commenting to Suhaib that XFree86's clipboard integration should
> be via cygwin.... I took a stab at it.
> 
> I've got /dev/clipboard accepting writes (only a single write() call at
> the moment :[ )... I'm working on allowing a series of sequential writes
> now...
> 
> Chuck - if you're on this list - did you find any documentation on how
> linux /dev/clipboard functions.
> 
> I.E. When you write 512 bytes, then wait 2 seconds then another 512
> bytes, can other applications read the 1st 512 bytes while you pause? Or
> does the write only occur on close() ?
> 
> 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.

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.
 
> Subject: /dev/clipboard
> Date: Thu, 22 Mar 2001 16:41:52 +1100
> From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
> To: <cygwin-developers AT cygwin DOT 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?)

> Todo:
> * Handle the core windows datatypes (ie translate dropped files into a
> list of cygwin paths, DIBS into binary data..)
> * 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.).
> * Allow arbitrary seek() calls.
> * Allow fstat() to return the current data size of the clipboard.
> * Allow ls /dev to show clipboard
> * Allow ls / to show /dev
> 
> 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.
 
> (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) ?

--Chuck