Re: NSPasteboard on X, what to do?

[Pascal Bourguignon]

> From: Richard Frith-Macdonald <richard@brainstorm.co.uk>
> Date: Wed, 9 Jan 2002 15:22:06 +0000
> 
> 
> On Wednesday, January 9, 2002, at 11:27 AM, Wim Oudshoorn wrote:
> 
> > You wrote:
> >> Well, they are both displaying on the same screen of the same machine.
> >> If I was controlling
> >> the keyboard and mouse of the machine to which the screen was attached,
> >> I'd expect to be
> >> able to select text in the other persons app, cut it to the pasteboard,
> >> move the mouse to
> >> my app, and paste it in.
> >
> > Ok, I see.  But in my definition I view this as a really big screen.
> > What I actually meant with screen was the X term Display.
> > (You see I get really confused.)
> >
> > So to translate back.  My idea was to group by the X notion of Display.
> 
> OK ... that's pretty confusing then ... as the X concept of a Display is
> pretty much what it sounded like you were referring to as a 'machine' ...
> ie it's someones workstation,  while the X Screen is more like an
> individual CRT or LCD device attached-to/part-of the machine.
> 
> That rather raises the question of what you were referring to as a
> machine did you mean some sort of back-end computational engine
> located at a  distance from the users workstation?  The OpenStep
> AppKit is very much  designed/used as a workstation tool, so it's
> rather unusual to use the term machine  that way in this context.
> 
> By the way ... I think the X term 'display' can easily be misleading
> ...  in normal english I think it's pretty synonymous with 'screen'.
> I'd prefer  to use the term 'workstation' for the chunk of equipment
> that a person sits in front of and physically interacts with.

It's a little more complicated than that.

In X terminology, AFAIK, there's no  'screen'. So this term is free to
refer to  the physical  screen, ie. the  monitor (and I  understand as
such), unless  it refers  to OpenStep screens,  which correspond  to X
displays.

So,  there are  X  servers. Each  X server  may  manage a  range of  X
displays. The  X display may be  mapped to video  RAM itself projected
onto the screen of a monitor.  But one may run several displays on the
same screen  (monitor). For  example, you could  have display  :0.0 on
vt07 and display :0.1 on vt08.

You could even run two servers  each with its own display(s), and have
for example, display :0.0 on vt07 and display :1.0 on vt08. Or more.


The  notion  of  machine   is  quite  irrelevant  in  this  networking
context. Ok,  there are machines (hosts, computers,  whatever), but it
does  not matter.  What  matter are  the  processes: applications  and
X-servers.

We should  assume that the  administrator configured the  X-severs and
the X-display  to match the usage  they have with  respect to physical
monitors, keyboards and persons (not users = UID).


The most  we can ask,  and what we  should expect, IMHO, is  that each
person wil  work with  his own  X-server. If a  person works  with two
X-servers  at the  same  time,  GNUstep should  consider  them as  two
persons (should  have two separate  pasteboards, and should  not allow
drag-and-drop between these two X-servers).

 
> >> I think they should be using the pasteboard server of the *machine* to
> >> which they are displaying.  So you could cut and paste between apps on
> >> any screen attached to that machine.  This model assumes that every
> >> screen
> >> is attached to a machine - I know that that is not 100% the case in X,
> >> where a screen may be a dumb X server, but I'd suggest that in such a
> >> situation it would be beast to designate some real server (where a
> >> pasteboard
> >> server process can run) as the owner of that screen.
> >
> > I am confused again. Are you saying that you want to associate the
> > pasteboard with the Display?
> 
> I think that's right ... the pasteboard system is designed to be
> associated with a particular workstation (and the CX term 'Display'
> corresponds to a workstation).  So the pasteboard server that an
> application should use is the one for the workstation upon whose
> screen(s) the app is visible.

I don't think that your notion of workstation is relevant here, unless
you agree  to say  that each of  your 'workstation' correspond  do one
'X-server'. A  X-display is  not a workstation.  There may  be several
X-displays managed by one X-server and used by one person.

There is  a pasteboard  managed by the  X-server. Well,  it's actually
called clipboad in X terminology.


> >> I was being stupid because I allowed myself to be trapped into the 
> >> model
> >> you presented where machines and screens are separate ...  the solution
> >> is trivial if you say that each screen is associated with a machine.
> >
> > Please no.  A display is NOT associated to one machine!
> 
> display == workstation == machine

No, no and no!
 
> I don't think anyone would want to associate a pasteboard server on
> a  remote mainframe, it needs to be associated with a workstation.

On some computer whereever,  you may have various processes X-servers,
each  running various  X-displays.  Each  X-display may  be  mapped to
various physical  monitors. You can setup several  workstations with a
set of X-servers and monitors.

For example you could have:

   One computer with three monitors A, B, C, two keyboards,
   and two X-servers :0 and :1. 

   Keyboard K - Server :0
   Keyboard L - Server :1
   Monitor A - vt07 - Display :0.0 - Server :0
   Monitor B - vt07 - Display :0.1 - Server :0
   Monitor B - vt08 - Display :1.0 - Server :1
   Monitor C - vt07 - Display :1.0 - Server :1

   Now you could have two persons  Jane and Joe in front of this setup
   and consider two workstations:

       Jane using her workstation consisting of Keyboard K, Monitor A,
       and Monitor B (vt07).

       Joe using  his workstation consisting  of Keyboad L,  Monitor B
       (vt08), and Monitor C.

   Each user could give back Monitor B to the other type Ctrl-Shift-F7
   or Ctrl-Shift-F8.


The conclusion here is that the physical components of a 'workstation'
are  not relevant  and may  be somewhat  virtual (vt07,  vt08). What's
important, for GNUstep, is to consider the X-server.

And since there's  enough freedom to configure the  X-servers to match
any setup,  we can just  base GNUstep on  them without trying  to move
date from one  X-server to another, even if  a GNUstep application can
have  windows on  different X-servers.  In this  case, I  say  that we
should accept  that no copy-and-paste  and no drag-and-drop  can occur
between  these  two   windows,  even  if  they  belong   to  the  same
application.

 
> >>> Two servers:  A, B
> >>> Two XDisplays: S, T  (one user behind S and one user behind T)
> >>> S is running two programs P1, P2
> >>> T is runnint two programs Q1, Q2
> >>>
> >>>         Server A,         Server B
> >>>
> >>> S          P1                P2
> >>> T          Q1                Q2
> >>>
> >>>
> >>> Now user S, selects something for the find panel, or
> >>> for copy/past in P1.  This ends up in the pasteboard of Server A.
> >>> Now S selects application P2, and reselects the find panel, or
> >>> pastes. NOTHING happens.   (note I am not talking DnD here)
> >>>
> >>> Afterwards user T opens the find panel or does a paste.
> >>> Voila, the content of what user S selected appears.
> >>
> >> If S is associated with A, then P1 and P2 should both use the
> >> pasteboard server on A ... and cut/paste should work as expected.
> >> The selection for P1 will appear in P2 and not in Q1 or Q2
> >
> > Why should S be associated with A??? and I assume that you want
> > to associate T with B.  I really can not imagine how you want
> > to set up these associations.
> 
> How about ... because you didn't say where any other servers were?
> The pasteboard servers have to run somewhere, so I assumed that
> server A would run the X server software controling X display S,
> and it would therefore make sense for the associated pasteboard
> server to run on that server also (minimising network traffic).

There's aready a  pasteboard in X-server (X clipboad).  For GNUstep on
X, we don't need a specific  pasteboard server ; just use the X-server
clipboard functions.

I don't  know how  DPS servers  other than that  of NeXTSTEP  work. It
seems that the pasteboard server  used on NeXTSTEP exists only because
the DPS  server of  NeXTSTEP don't implement  this feature  itself. In
that case, we  should consider the pasteboard server  (gpbs) a part of
the DPS server. 

GNUstep needs to implement a specific pasteboard server like gpbs only
when running with a DPS server which lacks such feature.


I've  not had  a close  look  at the  details of  NSPasteboard vs.   X
clipboard. It  seems to me that  X clipboard implements  all is needed
for NSPasteboard. But  in the event where we  needed more features for
NSPasteboard  over  X  clipboard,  we  should implement  them  in  the
back-end, not  in a separate  server, because we cannot  launch random
processes on  the same  host than the  X-server, and we  cannot assume
that  two  applications  using  the  same X-server  will  be  able  to
communicate one with the other or with a third common server.

For example, we could have a X-server  on a host with a private IP and
a public IP (or two different private IP) and no routing between these
two networks,  and each  application running on  another host  on each
networks.  In  that  case,  the  only way  the  two  applications  can
communicate  is  thru  copy-and-paste  thru  the X  clipboard  of  the
X-server where they have their windows.


> Seems we just have confusion because your original email said
> 'screen' rather than 'workstation' and 'machine' rather than
> 'remote backend computational engine' or some such.  The second
> naming problem is understandable - I can't think of a nice short,
> clear term to express that concept.

He meant  X display for 'screen'. 'workstation',  'host' and 'machine'
are not relevant.



-- 
__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------