Re: NSPasteboard on X, what to do?

[Pascal Bourguignon]

> From: Richard Frith-Macdonald <richard@brainstorm.co.uk>
> 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 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.

NeXTstep screen = X display

Displays are run by servers (NeXTstep screens are run by DPS servers).

Servers are run on computers that  are not necessarily the same as the
computers where the applications run. There's a n-to-n relation here.


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

If  you  s/screen/display/g  in  this  paragraph, you  could  add  the
distinction that physical  screens may be located far  apart from each
other  and therefore  we may  have  configurations where  not all  the
available display are grouped together. I think that in that case, one
should   configure   several  X   server,   one   for  eacl   physical
location.  (Think of  airport screens  for example  (too many  of them
running MS-Windows BSOD)).


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

Right, when both X displays are run on the same X server.


> >>> 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  point  is  that  the  host  where X  server  is  running  is  not
necessarily a GNUstep host, and most probably will not run gpbs. Think
X terminal  here. So we need to  use the X server  pasteboard. I don't
know  of any X  server not  implementing the  X pasteboard,  even when
running in a X terminal. I can't see any reason why not to use it.

I'm wondering  what use gpbs may  have... Why do we  need to designate
some  "real?" server?  Do  you mean  "host"  here? The  owners of  the
screens (displays) are the X servers of course.


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

Be carefull. User  is a unix notion = UID. Let's  speak of human being
in  front of  the work  stations as  "persons". Then  we may  have two
persons  in  front  of   two  keyboards  (X-inputs)  and  two  screens
(X-displays) connected  to the same  X-server.  Should they  share the
same pasteboard  in the same X-server in  that case? I say  yes. I say
that if one want them to have different pasteboard, then configure two
X-servers each with a different X-display and X-keyboard. To configure
both screens  as two X-displays on  the same X-server  is usefull only
when one person will work with both keyboards and displays.

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

One person  may be authorized  to run applications under  several user
accounts  on various  different  computers with  windows  on the  same
display.


> 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 only know of capacities to improve the situation.


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

Yes. Let's forget it and concentrate on Grouping by Server.


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

That's  not the case.  You may  have several  X-server running  on one
machine, each with several X-displays to various persons.

                            +-------------------+
                            |    Machine 1      |
           +-----------+    |                   |
        o  |Display 11 |-\  |  +-----------+    |
       /O\ +-----------+  \-|--| Server 1  |    |
       / \ +-----------+  /-|--|           |    |
           |Display 12 |-/  |  +-----------+    |
           +-----------+    |                   |
                            |                   |
                            |                   |
                            |                   |
           +-----------+    |                   |
        o  |Display 21 |-\  |  +-----------+    |
       /O\ +-----------+  \-|--| Server 2  |    |
       / \ +-----------+  /-|--|           |    |
           |Display 22 |-/  |  +-----------+    |
           +-----------+    |                   |
                            +-------------------+


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


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