[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSPasteboard on X, what to do?

From: Richard Frith-Macdonald
Subject: Re: NSPasteboard on X, what to do?
Date: Wed, 9 Jan 2002 10:17:07 +0000

On Wednesday, January 9, 2002, at 08:58 AM, Wim Oudshoorn wrote:
In MacOS-X (essentially OpenStep) I routinely perform a cut on one
move the mouse to an app on my other screen, and paste into the second
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

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

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]