Re: NSPasteboard on X, what to do?

[Richard Frith-Macdonald]

On Wednesday, January 9, 2002, at 08:58 AM, Wim Oudshoorn wrote:
> > In MacOS-X (essentially OpenStep) I routinely perform a cut on one
> > screen,
> > move the mouse to an app on my other screen, and paste into the second
> > app.
> > Similarly, I drag stuff from an app on one screen to an app on the 
> > other.
>
> Hm, I see your point, but I do not understand how dragging is supposed 
> to work.
> How do you drag from one screen to another?  (I have never
> used a multi headed machine, so bear with me)

The system is set up to 'know' where the screens are ... they are 
logically positioned
adjacent to each other in some way (normally you will set this logical 
configuration to
match the physical positioning on your desk).
When you move the mouse pointer to the edge of a screen, and then 
continue to drag the
mouse, the pointer appears on the adjacent screen.  It's really as if 
you had one big
screen made out of smaller screens tiled together.  For most people, 
such setups are
built with two video cards (or a dual port card) in their workstation, 
though I've seen
a few graphic designers using three or more screens on the same machine!
I have seen the same sort of setup linking multiple machines with X too, 
but I don't know
if NeXTstep ever supported a multi-machine version - I've never seen a 
NeXTstep app display
windows on more than one machine at a time, only on multiple screens of 
the same machine.


> > Most copy and paste operations are performed on a single machine ... 
> > I'd
> > venture
>
> Hm, still confused.  Suppose I log in to a server and set my Xdisplay 
> to my
> local machine.  Some other person does the same,  what do these 
> processes in
> common??

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.

Additionally, if I had two screens on my workstation, and someone on a 
different machine set
their app to display on one of my screens, I'd expect to be able to cut 
from that app and
then paste into an app in my other screen.

> > > 1. No DnD and copy/paste between different applications
> > > running on different computers but on the same screen,
> > > thereby going against the X philosophy.
> >
> > Not sure what you mean by this ... if you are receiving a drop from
> > an app on another machine, the -draggingPasteboard method provided by
> > the dragging info would return a pasteboard object connected to the
> > pasteboard server on which the drag originated.
>
> This certainly can work for DnD, but what about the other pasteboards?

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.

> > The aspect of this I've never been so happy about is the 'all'
> > What about a multi-screened, multi-keyboarded machine with more than
> > one user.  Do both users share the same pasteboard server?
> > I think ideally not.  Each user would get their own server (to which
> > they save data)
>
> Exactly! this is the problem.

The problem with this is that simply having per-user pasteboard servers
prohibits interaction between apps owned by different users.  This is
as undesirable as having completely free interaction.  The existing 
mechanism
of having a single pasteboard server per machine (rather than one per 
user)
is about as secure/insecure as permitting aps to display on the screens 
of
another machine in X.

An ideal solution requires interaction but also some security control.
The only control NeXTstep had was to deny/allow one machine to access 
anothers
resources ... pretty much the same as the degree of control X permits.

> > I completely disagree ... I hope I have shown above that the advantages
> > you list for doing this do not actually exist, while the disadvantage
> > you supply for grouping by computer does not exist.
>
> Well, I still think there are quite some problems with the grouping by
> Computer.

Any other than the security problem (which I think is not to do with the
machine/screen issue anyway)?

> >   How we cope with a cut and paste operation
> > between two apps on different machines (either on the same screen or on
> > two screens of one machine) I don't know.  I think this is the tricky
> > case
> > but it may be rare enough to ignore.

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.

> Actually, I do not think it is rare.  Maybe the following hypothetical
> situation will show some problems.  (You probably are already aware
> of them)
>
>
> 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