Re: NSPasteboard on X, what to do?

[Pascal Bourguignon]

> Date: Thu, 10 Jan 2002 10:51:05 +0100
> From: Dennis Leeuw <dleeuw@made-it.com>
> 
> Pascal Bourguignon wrote:
> 
> > >     Sender: dennis@made-it.com
> > > Date: Thu, 10 Jan 2002 10:30:13 +0100
> > > From: Dennis Leeuw <dleeuw@made-it.com>
> > >
> > > Pascal Bourguignon wrote:
> > >
> > > > > Date: Thu, 10 Jan 2002 08:12:03 +0100
> > > > > From: Dennis Leeuw <dleeuw@made-it.com>
> > > > >
> > > > > Hi all,
> > > > > The machine, and I talk about the hardware (harddisk), that has a 
> > > > > GNUstep
> > > > > app that you want to run also has gpbs installed. If that is started 
> > > > > at boot
> > > > > time, we have a gpbs server running that is machine dependend.
> > > > >
> > > > > If every user get's a temporary database in his/her home dirctory that
> > > > > records all cuts and the gpbs server it is stored on, you could then 
> > > > > paste
> > > > > it in every app the user is running.
> > > > >
> > > > > Downside is the network traffic...
> > > > >
> > > > > Dennis
> > > >
> > > > Ok. Let's suppose that you have the following configuration:
> > > >
> > > >     hostA1 10.0.0.1 running gs App1 and gpbs server1
> > > >     with DISPLAY=10.0.0.2:0.0
> > > >
> > > >     hostA2 212.87.205.57 running gs App2 and gpbs server2
> > > >     with DISPLAY=212.87.205.58:0.0
> > > >
> > > >     and
> > > >
> > > >     hostX3 with two ethernet cards eth0 212.87.205.58
> > > >                                and eth1 10.0.0.2
> > > >            running a X server, display :0, screen :0.0
> > > >
> > > > Now, on hostX3, you copy data from a window of App1, and paste it to a
> > > > window of App2.
> > > >
> > > > Please explain  how this  can be  done by your  gpbs server1  and gpbs
> > > > server2. Remember that gpbs server1 is  on a host on a private network
> > > > and that no  routing exists between 10.0.0.0/8 and  the Internet where
> > > > gpbs server2 is.
> > >
> > > If hostX3 knows about routing then the problem is solved, but I
> > > guess that is not what you are aiming at.  You mean if hostX3
> > > doesn't know about routing... well I guess you are stuck and should
> > > be.  The reason why hostX3 doesn't know about routing is probably a
> > > security issue. So if you could bypass the security AS A NORMAL USER
> > > by copy and paste, well...  (fill in yourself)
> >
> > Well,  in that  case,  users  will see  that  they can  copy-and-paste
> > between  any  X application  (Gnome,  KDE,  others),  and not  between
> > GNUstep applications,  and they will conclude  rightfully that GNUstep
> > is not up to its promise.
> >
> > Anyway, even  with all three hosts on  the same LAN, I'd  like to hear
> > your idea of the sequence  of events when copy-and-paste is done. Note
> > that you're  involving two gpbs servers, and  the GNUstep applications
> > don't know each other. Then?
> 
> User presses copy in App1 -> gpbs1 accepts data and copy function
> sets database with someting like server1:data

> User does paste in App2 -> paste function looks up database and sees
> data is on server1, 

How?  

How the  App2 can know  that something has  been copied and  stored on
server1 and not on server3 or on server4?

> notifies gpbs2 that data should be coming from gpbs1 and notifies
> gpbs1 to send data to gpbs2 -> servers exchange data -> gpbs2 sends
> data to App2

So [app2 notify:gpbs2 getDataFrom:gpbs1]
   [app2 notify:gpbs1 giveDataTo:gpbs2]
   [gpbs1 sendsData:data to:gpbs2]
   [gpbs2 receiveData:data from:gpbs1]
   [gpbs2 sendData:data to:app2]

Very simple isn't it.



My proposition  is to implement NSPasteboard in  the xgps/xdps backend
where:
 
To copy ( [app2 sendDataToXclipboards:data] ):
   
   - the data  writting methods of NSPasteboard gather  and encode the
     data into X  clipboard buffers. This should not  be too difficult
     because of  the similar structure  (provision for data  type with
     ICCM target atoms and to define custom atoms).

     The  various OpenStep  pasteboard  could be  implemented here  as
     different data types of as custom data types, or perhaps with the
     private_id.

   - when the  copy must  be enacted, the  data is  sent to all  the X
     displays on which  the application has at least  one window open,
     using the XmClipboardCopyXxx functions.

To paste ( [app1 receiveDataFromXclipboards:data] ):

   - the clipboards on all the X displays on which the application has
     at least one window open should  be polled to select the one from
     which we'll take data (the most recent). May be we'll have to add
     a  timestamp to the  copied data,  or may  be giving  the correct
     timestamp parameter to XmClipboardStartRetrieve will be enough.

   - retrieve the data  from the selected X clipboard,  and convert it
     to the data type expected by NSPasteboard.


Such an implementation would  allow GNUstep application to communicate
thru   their   X  displays,   either   for   copy-and-paste  and   for
drag-and-drop, and moreover, this will  be compatible with the other X
applications. This would work in any configuration :

   - local applications running along the X server on one host,

   - various applications on different hosts with their windows on one
     same X display.

   - when an application has windows  on different X displays, it will
     be able  to interact (copy-and-paste) with  other applications on
     one X display or the other.


-- 
__Pascal_Bourguignon__              (o_ Software patents are endangering
()  ASCII ribbon against html email //\ the computer industry all around
/\  and Microsoft attachments.      V_/ the world http://lpf.ai.mit.edu/
1962:DO20I=1.100  2001:my($f)=`fortune`;  http://petition.eurolinux.org/

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/IT d? s++:++(+++)>++ a C+++  UB+++L++++$S+X++++>$ P- L+++ E++ W++
N++ o-- K- w------ O- M++$ V PS+E++ Y++ PGP++ t+ 5? X+ R !tv b++(+)
DI+++ D++ G++ e+++ h+(++) r? y---? UF++++
------END GEEK CODE BLOCK------