Re: NSPasteboard on X, what to do?

[Pascal Bourguignon]

Willem Rein Oudshoorn <woudshoo@xs4all.nl> wrote:
> 
> 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.

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

That means running on a single X display.

Now, for NSPasteboard  on X:

Since  one application  could  open windows  on  screens on  different
displays (one window on host1:0.0, another on host2:3.1), the *all* is
relative to one or the other X display.

To avoid confusion, you have  to discriminate the "conceptual" part of
NSPasteboard from the actual object within the application.

There is  a NSPasteboard instance in each  application.  This instance
represents and  encapsulates the all the X  clipboards the application
has access to thru its windows on various X displays. Each X clipboard
is obviously shared by *all* applications  that have a window in the X
display where the X clipboard resides.


        Display A:0 - clipboard A
          Screen A:0.0
            Window 11 --------------------- Application 1
            Window 21 ---------------+        NSPasteboard instance 1
                                     |
        Display B:1 - clipboard B    +----- Application 2
          Screen B:1.0               |        NSPasteboard instance 2
            Window 22 ---------------+                     
            Window 23 --------------------- Application 3
                                              NSPasteboard instance 3


So,  one  application  may  have  to deal  with  several  X  clipboard
(transparently thru its NSPasteboard instance).


> 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
                              = X display (AFAIK)
> is the best mapping we can get.

Probably better to enunciate the mapping as:  workstation <-> X display 

> 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

Seems difficult to me because  the pasteboard servers may not have the
same connectivity to  the X servers and display  than the applications
they  serve (which  means that  anyway the  communication  between the
pasteboard servers of two different applications may have to pass thru
the X server anyway!).

> 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


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