Re: NSPasteboard on X, what to do?

[Richard Frith-Macdonald]

On Wednesday, January 9, 2002, at 04:40 PM, Pascal Bourguignon wrote:
> > > t 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.

Or run the pasteboard server for that X machine on one of the machines
where GNUstep *IS* running (this would be trivial).

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

Well, we do use it ... for communication with X apps.   The reasons to
only use it for that are: portability, complexity, efficiency.
Using a native GNUstep pasteboard is portable.
Massaging X APIs to fit the OpenStep model is non-trivial!
Using the X pasteboard for everything we would need to duplicate loads
of stuff we get for free.

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

There are times I hate living in an X-centric world, and have to remind
myself that people really are asking quite reasonable questions.  Despite
using X apps daily, and having done quite a bit of programming with it,
I just don't think the X way.  I'm still more familiar with alternative
worldviews :-)

I was talking about where to run a pasteboard server, not where to run
the X server.  From that point of view, the 'ownership' of the screen
has *nothing* to do with X.

By 'designate', I merely mean select.  That selection could be done
in many ways -

eg.
We could have a single powerful server machine running GNUstep
pasteboard servers on behalf of a bunch of X terminals which can't
run them locally.  If the users of those X terminals used GNUstep,
and executed their apps on the same big machine, the result would
be a much more efficient system as the cut and paste and drag and
drop traffic would all be on the one machine rather than having to
go to and from each X terminal.

We could just have any GNUstep app start up the pasteboard server
for an X terminal the first time it tries to access the pasteboard
(as happens in the current code).

We could set up a mixed policy of some sort.

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

An X display is apparently *not* a screen.
From the XLib manual ...
'a display is defined as a workstation consisting of a keyboard, a 
pointing device suck as a mouse, and one or more screens.'

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

I think we are all happy with that.

Only I'm using the term 'workstation' because I'm not restricting my
thinking to X (and because 'machine' turned out to be too confusing).

One pasteboard server per workstation.  The pasteboard server to usually
(but not necessarily) execute on the workstation.

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


However, I was using 'machine' in the sense of 'workstation',
which corresponds to an X display, or a NeXTstep host rather
than a backend server.