Re: NSPasteboard on X, what to do?

[Pascal Bourguignon]

> From: Richard Frith-Macdonald <richard@brainstorm.co.uk>
> Date: Wed, 9 Jan 2002 07:59:35 +0000
>
>
> On Tuesday, January 8, 2002, at 10:04 PM, Willem Rein Oudshoorn wrote:
>
> > - Every computer had ONE dedicated screen all for itself.
>
> No. A single application could have windows displayed on multiple
> screens on one machine.  It could also display on another machine
> (though I'm not  sure about using multiple displays on different
> machines).

Effectively.    For    example,   with   emacs   one    can   do   M-x
make-frame-on-display   and  have  frames   (X  windows)   on  various
computers.  I'm used  to do  it to  continue work  on laptop  and back
without interrupting compiles and edits...

One could  envisage a  window manager that  would integrate all  the X
displays available  on the LAN in  one workspace, with  the ability to
move windows from one computer to another on the fly.


> > On X this IS an issue.  So in order to give some meaningfull
> > interpretation to the class description let's examine the
> > kind of NSPasteboards that are documented.
> >
> > The different NSPasteboards
> > ---------------------------
> >
> > * General Pasteboard  (ordinary cut, copy paste operations)
> > * Font Pasteboard  (support copy font, paste font)
> > * Ruler Pasteboard (support copy ruler, paste ruler)
> > * Find Pasteboard (active applications find panel)
> > * Drag Pasteboard (well, DnD of course)
> >
> >
> > So this clearly suggusts that the *all* is grouped by Screen.
>
> Not to me.  I see dragging and cut-and paste as inter-screen operations -
> I want them to take effect wherever the mouse pointer is.
>
> 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.

An important feature indeed.


> [...]
>
> > So I hope that someone can explain to me how we are going to
> > interprete the concepts `Application' and `all' in GNUstep.
>
> I'm pretty sure that the term 'application' is generally meant to
> describe a process which uses the AppKit.
>
> 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)

Well, in  my emacs  example, since emacs  has windows on  two displays
with two keyboards, two users could edit simultaneously two buffers in
the  same emacs,  or even,  fight for  edits in  the same  buffer.  Of
course, since  emacs is not  multithreaded, there may be  conflicts at
some times. But  what I mean here is that  users are not distinguished
by the X keyboard or even by the X server.

The only thing one can say  about the user, is that he's identified by
the  UID of  the  application  process.  If  the  user configures  his
application to  run with  windows on other  servers, other  hosts with
other  displays and  keyboards, it's  his responsibility  to  assure a
different person  interacts with his  applications in his name  and in
synchronization with him.

In  that kind  of configuration  I  would expect  a copy  done at  one
keyboard,  to use  the same  pasteboard  as used  by a  paste done  at
another one.

Of  course,  if  the  copy  were  done  at  keyboard  one  in  another
application, it would not go to the same pasteboard.

On another hand, with the following configuration:

 +-------------------------+ +-------------------------+
 | display 11 on server 1  | | display 12 on server 1  |
 | +---------+ +---------+ | | +---------+ +---------+ |
 | | win 111 | | win 112 | | | | win 122 | | win 123 | |
 | |  app 1  | |  app 2  | | | |  app 2  | |  app 3  | |
 | | user a  | | user b  | | | | user b  | | user c  | |
 | |         | |         | | | |         | |         | |
 | +---------+ +---------+ | | +---------+ +---------+ |
 |                         | |                         |
 |                         | |                         |
 +-------------------------+ +-------------------------+


 +-------------------------+
 | display 21 on server 2  |
 | +---------+ +---------+ |
 | | win 214 | | win 212 | |
 | |  app 4  | |  app 2  | |
 | | user d  | | user b  | |
 | |         | |         | |
 | +---------+ +---------+ |
 |                         |
 |                         |
 +-------------------------+

(Note that app  1, app 2, app 3  and app 4 may run on  any computer of
the network).


Should  win 112 and  win 122 share the same pasteboard?
(Two  windows of  the same  application on  the same  X server  but on
different displays).

Should  win 112 and  win 212 share the same pasteboard?
(Two windows of the same application on different X servers.



I would  expect drag-and-drop to  function between all windows  of the
same server.

Since I  don't know  of any  window manager that  integrate in  a same
desktop   displays  on   different   servers,  I   would  not   expect
drag-and-drop  to function  accross  servers. Anyway,  this  is not  a
native feature of X, this  would need some way of redirecting displays
from  one server  to another,  or  application level  support to  move
windows from one server to another. (Note that emacs frames created on
different servers cannot be moved to another server).


I would expect  copy-and-paste between all windows of  the same server
to  work. That  is, in  particalar, the  following sequence  should be
possible:

  - person at display 11 (server 1) copies data X from win 111 of app 1.

  - person at display 12 (server 1) selects win 123 of app 3.

  - person at  display 12 (server  1) paste data  into win 123  of app
    3. Data X is pasted.


Now, while I would not expect copy-and-paste to work between different
X servers, data can still be pasted from win 214 into win 212 and thus
be available to app 2 on win 112 and win 123.

I think that allowing for a  common pasteboard between win 214 and win
123, or  even between  214 and  win 122 just  because it  happens that
there is an application using both  server 1 and 2 poses more problems
than the advantage it would offer.


Note  however that  these  distinctions are  not  related to  physical
disposition of screens and computers. We could have the three displays
mapped to three screens on the same desk, with both servers running in
the same computer,  and our separating of pasteboard  would be seen as
an  artificial limitation.  And  each displays  could be  separated by
kilometers and  three different persons  could interact with  the same
application app 2,  and person at display 11 and  person at display 12
would share  the same  pasteboard and  this too would  be viewed  as a
problem.  However these  different physical  configurations  should be
handled in the  configuration of the X servers: in  the case where the
displays are not to be  integrated in one desktop, the computer should
run two X servers.


So, my conclusion would be that what is needed is Grouping by X Server.


> > I think for the Pasteboard we can should settle on Grouping by
> > Screen
>
> 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.
>
> > The pasteboard is part of AppKit/GUI so any application trying to
> > use the NSPasteBoard should have some concept of Screens.  At the
> > moment AppKit only supports one screen, so multiple screens is no
> > problem.  If GUI is going to support multiple screens per
> > Application, we need an extension of the NSPasteboard.
>
> We don't need any changes to support multiple screens ... where we
> will start to need to work on things is when we get multiple
> machines sharing the same screen.  When that happens we need only
> ensure that the internals of the DnD system supply a pasteboard to
> the app which is connected to the correct pasteboard 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.

In the  case of X windows,  there is a  pasteboard in the X  server to
handle  this  case. Note  that  two  GNUstep  applications could  have
windows on  a X display in  a X server  that does not run  GNUstep (no
gpbs  process).  However,  we  could still  implement a  communication
between these two application thru the X server. Perhaps without doing
anything more  than for the  communication between X  applications and
GNUstep applications.


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