Re: NSPasteboard on X, what to do?

[Pascal Bourguignon]

> From: Richard Frith-Macdonald <richard@brainstorm.co.uk>
> Date: Wed, 9 Jan 2002 16:57:01 +0000
> 
> > Workstation - The chunk of equipment you are sitting behind
> >     that is:
> >            - keyboard
> >            - XDisplay
> 
> <pedantic> actually an X Display includes the keyboard and mouse 
> </pedantic>

<super-pedantic> I don't see that:

Section "ServerLayout"
        Identifier     "Layout[all]"
        Screen      0  "Screen[0]" 0 0
        Screen      1  "Screen[1]" RightOf "Screen[0]"
        InputDevice    "Keyboard[0]" "CoreKeyboard"
        InputDevice    "Mouse[1]" "CorePointer"
        Option         "Clone" "off"
        Option         "Xinerama" "off"
EndSection

So I would  say that mouse, keyboard and screens  are connected to the
X-server, not to the display. Moreover, note that:

Section "Screen"
        Identifier "Screen[0]"
        Device     "Device[0]"
        Monitor    "Monitor[0]"
        DefaultDepth     24
        SubSection "Display"
                Depth     15
                Modes    "1152x870" "1024x768" "800x600" "640x480"
        EndSubSection
        SubSection "Display"
                Depth     16
                Modes    "1152x870" "1024x768" "800x600" "640x480"
        EndSubSection
        SubSection "Display"
                Depth     24
                Modes    "1280x1024" "1152x870" "1024x768" "800x600" "640x480"
        EndSubSection
        SubSection "Display"
                Depth     32
                Modes    "1152x870" "1024x768" "800x600" "640x480"
        EndSubSection
        SubSection "Display"
                Depth     8
                Modes    "1152x870" "1024x768" "800x600" "640x480"
        EndSubSection
EndSection

So a 'X-screen', may have  several displays, not only one.  Well, with
virtual consoles, it's a little more complicated. But anyway, my point
is that keyboards, mice and  screens are actually connected and belong
to a given X-server, as well as the displays. The events coming from a
given keyboards go to the  X-server which then dispatch them to either
display  it happen to  have depending  on the  active window  thru the
window manager.

</super-pedantic>

>[...]
>
> >>> Please no.  A display is NOT associated to one machine!
> >>
> >> display == workstation == machine
> >>
> >
> > This is something I still disagree with.
> 
> I was defining the terms as I read them from the context of your
> original email.  You have just redefined them again.  I don't see
> much point in this -  the previous emails won't make sense with new
> definitions of terms, and if we can't  already work out what was
> meant, another round of redefinition will not help.

I think that when  speaking of GNUstep on X, we should  stick to the X
terminology and map OpenStep terminology to X terminology. And there's
no need to cite terms of  lower level (hardware related terms) only to
give example of physical configurations.

Therefore we have these important notions:

      X server running:
          one X clipboard     corresponding to one NSPasteBoard (*)
          several X display   corresponding each to one NSScreen

(*) Care should be taken that a GNUstep application may have different
NSWindows mapped  to different NSScreens corresponding  to different X
displays in different X servers, therefore one GNUstep application may
have to deal with different X clipboards.

This means  that when we copy  something in a  GNUstep application, we
may have to  send this data to several X  servers, if this application
has windows on several X servers.

Note that  for now, GNUstep is  not able to agreate  in its +[NSScreen
screens] all the X display of all the X servers on which it can open a
window.  This  would imply  scanning the whole  Internet for  X server
having  a xhost  +ourhost, or  whatever other  authorization  given to
us. But something should be done  about it because that's the only API
we have to portably open a NSWindow on a given NSScreen whatever the X
server it may run on.


> [...]
>
> In the days of NeXTstep/OPENSTEP, people used to talk about
> 'running'  Apps on remote hosts by specifying NXHost at the command
> line.  In NeXT/OpenStep terminology,  what is important is the host
> on which the app is running/displaying (not the one on which  the
> code is executing) and the pasteboard server used executes on that
> machine.

Not at all.   The -NXHost argument is ill-named.   It is equivalent to
-display of X applications. It actually names only the DPS server, not
a  specific NSScreen  (which  was not  very  important to  distinguish
because a NSWindow can easily be moved to a given NSScreen by the user
and can remember its screen position).


You would do:

[hostA]% rsh hostB /Apps/MyApp.app/MyApp -NXHost hostA

to run MyApp on hostB and have it display on hostA, not the reverse.


> [...]
> 
> >> How about ... because you didn't say where any other servers were?
> >> The pasteboard servers have to run somewhere,
> >
> > Well, no.
> > I am not sure anymore that we really need a pasteboard server.
> > If the pasteboards are associated with an XDisplay (talking about
> > the xgps backend) it makes sense use the XSelection mechanism
> > to represent the PasteBoards.
> 
> As you note, that's only true if you are talking about an X backend -
> so the existing code has the advantage of portability.

Effectively.   A separate pasteboard  server is  only needed  when the
window  server does  not implement  itself  a pasteboard,  as DPS  did
not. But when  we're using a window server that  does, let's just have
the corresponding backend use it.

 
> Also, while the broad capabilities of the X clipboard system roughly
> match those of the OpenStep pasteboard, when it get down to detail there
> is a lot of work involved in getting an X based system to conform to
> the OpenStep API/behavior.  Replicating the more advanced functionality
> available for communication between GNUstep apps using the X clipboard
> would take weeks of work (eg. the pasteboard server will transparently
> put GNUstep apps directly in touch with each other via distributed 
> objects).

That may well be not possible. The only communication path between two
GNUstep application could be only  the X-server. In case of GNUstep on
X,  it's  better not  to  count  on any  other  mechanism  than the  X
clipboard to implement NSPasteBoard.


> For communication with X apps, we have to map between the two systems ...
> but for that we only need to implement the common core of functionality
> that both X and GNUstep apps use, and the mechanism for that was fairly
> straightforward.


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