Re: NSPasteboard on X, what to do?

[Pascal Bourguignon]

These questions are also related to the configuration of the system.

I agree to call 'workstation' the set of element a given person uses.

In that case,  when we're using GNUstep on X,  let's map a workstation
to a given X-server.


Note that nothing in X prevent a given person to use various X servers
at the same  time.  Only that an atomic  inter-relation is always done
between one person and one X server.

My point here is that  there are configuration objects and sematics in
X that allow the administrator of  a X system to configure it to match
a given setup (set of hardware  and software) to a given usage (set of
persons  using the  system in  a set  of roles).  Therefore,  we could
profit  from this  confugurable layer  and map  GNUstep concepts  on X
concepts in a meaningfull and useful way.

Otherwise, we will  need to configure the GNUstep  system too and this
may lead to confusion and incoherencies.

I'm supposing that one GNUstep setup will only use one kind of backend
(in the case  at hand, only X  xgps backend). Do we want  to allow the
configuration of a GNUstep  application running with two NSScreens one
on  a DPS server  and another  on a  X server,  thus running  with two
different backends at the same time? 


So, in  the case  where we  have a system  made of  X servers,  pure X
applications, and GNUstep applications with a single X backend, I say:

    Let's say that we'll map a workstation to a X-server session.

    Let's say however that we'll agree to have one GNUstep application
    open   windows   on   NSScreens   mapped  to   various   different
    X-server. (*)

    Let's say that  we'll map NSPasteboard to the  set of X clipboards
    in  the X servers  the application  is (indirectly  thru NSScreen)
    using.

This has the advantage of:

    - not   needing  any   configuration  other   than   the  X-server
      configuration, and  the specification  of the X-servers  a given
      application  may  use  (to   gather  the  NSScreens  on  various
      X-servers).

    - being integrated with the pure X applications.

    - being able to run GNUstep  application in any X configuration as
      complicated or as simple as it can be.


(*): Note  that this  means that one  application may have  windows on
different  workstations, that  it  may receive  events from  different
window servers  (X servers)!  Is there  anything in the  X backends of
GNUstep that support  that, or at least that  don't prevent that? Does
the front-end consider the agreagation  of all X servers as one window
server?

   In the case of emacs  with windows in different X-servers, that is,
   when a single emacs process  is used on two different workstations,
   emacs    manages   one    cursor   (or    insertion    point)   per
   workstation. Therefore,  it's possible for two persons  to edit the
   same buffer,  inserting text  at two different  places in  the same
   buffer at the same time. Well,  same time modulo the fact that when
   emacs  enters a  'modal  loop'  (like in  the  mini-buffer) on  one
   'workstation', the other editing is suspended (input characters are
   queued). That is,  emacs is not multithreaded, but  is able to work
   with several window server at the same time.

Of course  such a feature  is very usefull  for some kind  of software
(think groupware).


We could  map a  GNUstep 'workstation' to  something different  than a
X-server, but to do that we would need a configuration file describing
underlying  elements   and  the  linking  of  those   to  the  GNUstep
workstation (like XF86config). I'm not sure it's worth the work.


Of course, the code in the NSPasteboard back-end is specific to X, and
it  means  that  another  back-end  will have  to  implement  its  own
NSPasteboard slice.

But implementing a general pasteboard  system poses the problem of not
being integrated  with the underlying window server.  From a political
and  strategic point of  view, it's  better to  be well  integrated to
whatever window system we happen to be running on.

My view is that the pasteboard server existed in NeXTSTEP only because
it was  not implemented  into the DPS  window server. Problems  with a
separate  pasteboard  server:  what  to  do  when  there  are  several
applications  running with  different  UID?  On  NeXTSTEP, since  both
applications will display  on the same window server,  even when there
are two  screens, a copy-and-paste between both  application will work
as expected, and since it's impossible to configure two workstation on
NeXTSTEP systems,  there's no  problem. But on  other systems,  and in
particular  with X  window  servers, it's  possible  to configure  two
different  workstation on  a multi-header  host, with,  logically, two
X-servers, each  with its own  clipboard, allowing two persons  to use
the system at the same time. Now a GNUstep pasteboard server will have
either to  manage two separate spaces,  or we will need  to launch one
pasteboard server  for each  workstation (person). Actually,  we would
have to reimplement all the  clipboard management of the X server into
the GNUstep pasteboard server to  be able to handle properly this kind
of configurations.

Even  with  a  DPS  window  server, we  could  have  multi-workstation
configurations.  I'm  not sure  that  the  NeXTSTEP  pbs would  behave
gracefully in that kind of configurations.


That's why  I think that here,  it would be better  to implement these
features in  the back-end and in  a window server specific  way. If we
need a  separate pasteboard  server for the  window server  that don't
have one,  ok. But for those  like X, MS-Windows, Aqua  that have one,
it's better to use their specific clipboard.

And in  anycase, even if we  had a separate pasteboard  server, in the
case of the X backend we  will need to comunicate with the X clipboard
anyway to be compatible with pure X applications.


> Date: Wed, 9 Jan 2002 17:55:44 +0000
> From: Richard Frith-Macdonald <richard@brainstorm.co.uk>
> 
> 
> 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.'

Well, I may be mixed here. I'm  using the terms as used in practice in
the  programs  and  configuration  files.  This may  differ  from  the
theorical names  found in the  documentation which I haven't  read for
several years.
 
> >   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.
> 
> 
> 


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