[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSPasteboard on X, what to do?
From: |
Pascal Bourguignon |
Subject: |
Re: NSPasteboard on X, what to do? |
Date: |
Fri, 11 Jan 2002 16:45:59 +0100 (CET) |
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------
- Re: NSPasteboard on X, what to do?, (continued)
Re: NSPasteboard on X, what to do?, Willem Rein Oudshoorn, 2002/01/10
- Re: NSPasteboard on X, what to do?,
Pascal Bourguignon <=