Re: NSPasteboard on X, what to do?

[Richard Frith-Macdonald]

On Wednesday, January 9, 2002, at 03:47 PM, Wim Oudshoorn wrote:

> You wrote:
>
> > That rather raises the question of what you were referring to as a
> > machine
> > did you mean some sort of back-end computational engine located at a
> > distance
> > from the users workstation?  The OpenStep AppKit is very much
> > designed/used
> > as a workstation tool, so it's rather unusual to use the term machine
> > that
> > way in this context.
> >
> > By the way ... I think the X term 'display' can easily be 
> > misleading ...
> > in
> > normal english I think it's pretty synonymous with 'screen'.  I'd 
> > prefer
> > to
> > use the term 'workstation' for the chunk of equipment that a person 
> > sits
> > in front of and physically interacts with.
>
> Ok, lets try again:
>
> Workstation - The chunk of equipment you are sitting behind
>     that is:
>            - keyboard
>            - XDisplay

<pedantic> actually an X Display includes the keyboard and mouse 
</pedantic>

> And the Workstation - User interaction is managed by an X server.
> So from a software point of view, the Workstation is identified by
> an XDisplay.

Yes ... when you are running under X.  Without X you may have different 
terminology of course.
Also, pedantically speaking, I think an X display definitively does no 
non-display work, while
a workstation usually does.

> Machine - Just an ordinary computer, which is capable of running
>         GNUstep programs.
> Note that because there are dumb X-terminals,  the collection of
> Workstations is not a subset of Machines.  But in most cases
> a Workstation is a Machine.  (So I probably should use
> the term Computer here, but I do not want to introduce
> again a new term)
>
>
> > > 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.

To re-iterate.  In your original email you contrasted 'screen' with 
'computer', which
I read as contrasting 'screen' with 'workstation'.  Then you clarified 
this as actually
meaning 'X display' when you said 'screen' and now you are saying that 
you define
'machine' as any arbitrary machine on which GNUstep can run (sorry, I 
inadvertantly
introduced 'machine' as a synonym for 'computer').

Looking back at the original -

> Computer - Instance of a operational operating system.  (that is one
>            computer)
> Screen - A `monitor' used to display the output of
>          the application
>
>          App Name,     running on Computer,    displaying on Screen
>
> Simple     App A          X                     S (attached to X)
> Distrib1   App B          X, Y                  S (attached to X)
> Mscreen    App C          X,                    S, T (both attached to 
X)
> screen2    App D          Y                     S (attached to X)
> screen3    App E          X                     U (attached to Y)
> Mscreen2   App F          Y                     S, U (attached to X 
and Y)


It seems that you are actually quite clear ... my assumption that you 
meant
workstation was unwarrented (though not unreasonable in the context I 
hope).

However, you also seem quite clear that when you wrote screen you meant 
it.
A monitor attached to a computer.  Not multiple monitors, no keyboard, 
no mouse.
So there has definately been confusion.

I really think my last couple of emails should have been quite plain 
though ...

The pasteboard server used by an application should be associated with 
the workstation
that the user of the application is seated at.
The computer that the application code is executing on is irrelevant.
The exact screen(s) that the application is using are irrelevant.

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.

So 'running' an app on a particular host is pretty much synonymous with 
setting an X app to
use a particular display.

>  Assume the following fictional
> session on my computer:

> ----------------------------
>  XTerm (1) running on S
>
>  telnet A.is.a.computer
> > setenv DISPLAY=S:0.0
> > openapp GWorkspace.app
>
> ----------------------------
>   XTerm (2) running on S
>
>   telnet B.is.a.computer
> > setenv DISPLAY=S:0.0
> > openapp TextEdit.app
>
> ---------------------------
>
> Now at this moment I have on my Workstation S
> two GNUstep applications.
> and the equality
>
> display == workstation == machine
>
> does not hold, workstation != machine
> for both GNUstep applications.

Only because you have redefined 'machine' to be the computer on which 
the GNUstep
app is executing.  I defined it as the workstation ... both apps are 
using your
workstation, so both would expect to use a pasteboard server associated 
with your
workstation.  NB.  I have been using the word 'associated' throughout, 
because there
is no reason other than network traffic efficiency why the pasteboard 
server
associated with a workstation had to be running on that workstation.

> Another potiental problem arises when
> S is really a Computer, but without GNUstep installed.
> In this case it is also impossible to use S as an Pasteboard server.

Yes ... but there is no strong reason why you would want to.

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

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

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.