Re: NSPasteboard on X, what to do?

[Willem Rein Oudshoorn]

First of all, I apologize for the confusion I have caused.

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

Sorry, I was just trying to get a grip on the terminology, and
was not thinking about my previous mails.
So please interprete what I am going to write now as a fresh start.

I had trouble interpreting the OpenStep specification of the NSPasteboard.
The documentation states that NSPasteboards are shared between 
*all* applications.
And it was not clear to me what was meant by the *all*.

So reading your reply I gather that

*all* means all applications running on a single wokstation.

If we agree on that, than we can try to figure out how this maps
into X.

Now what are the priorities, at least for me, for the mapping to
X concepts.

1 - The NSPasteboard should comply to the OpenStep spec.
2 - Given the constraint 1 we should try to integrate as 
    good as possible with the host environment. (At the moment
    being X)

As far as I understood the discussion, it seems that


   OpenStep                  X

   wokstation              XServer

is the best mapping we can get.

Now the task is to find an implementation of the NSPasteboard
that fully implements the OpenStep semantics using this mapping.

The current implementation DOES, as far as I can see,
fully implement the OpenStep semantics, but does not honor
in all cases this mapping.

So there are two questions:

A) Can we improve this situation
B) Is it worthwhile to improve this situation.

I think the answer to B is YES, because the main backend
of the moment is running on X and will not go away quickly.

So lets look at A.

The naturally idea, and suggested by some, is to get rid
of the gpbs/xpbs and just use the X mechanisms.   
However the problem with that is that the plain X mechanism
does not provide the OpenStep semantics. 

It seems to me that there at the moment roughly two
approaches:

A - use pasteboard servers just like it is now, but
    identify the pasteboard by XServer
B - write the pasteboard mechanism into the backend
    and the backend will use X mechanisms make it work.

Now both can work.  From an X point of view B seems more natural,
and from an OpenStep point of view I guess A is more natural.


NOTE, I think B can be made to work, if it is worth the effort
is another issue. And also note that I am not an experienced X
programmer.  

How could B work?
-----------------

As far as I can see there are 3 kind of pasteboard:

Generic   <--->  PrimarySelection (X standard)
Drag      <--->  DragSelection   (xdnd)
Other     <--->  XSelection

Let's look at the Other case.   For the other case we can
implement ontop of the normal XSelection semantics our own layer:

E.g.  To know which types are present on the pasteboard, use
an XConvertSelection with targetType == GSTypeList, 
or if we want any other information regarding the selection
we just convert it to suitable type to retrieve the information.
This information can be anything, so it should be possible to 
push around Distributed Objects.

For the Generic pastebaord and the Drag pasteboard 
the same hold, while talking to other GNUstep apps it is possible
to use these conversions.  For non GNUstep apps we have to
conform to the bare bone standards anyway.

However approach A has it advantages:

* Is already there and working.

And most of the advantages that approach B will have are just
as easily implemented in approach A.

However I do not think that portability is a big advantage of A,
the pasteboards are a responsibility of the backend.


Wim Oudshoorn