Re: NSPasteboard on X, what to do?

[Pascal Bourguignon]

> Date: Wed, 9 Jan 2002 18:45:12 +0000
> From: Richard Frith-Macdonald <richard@brainstorm.co.uk>
> 
> 
> On Wednesday, January 9, 2002, at 06:16 PM, Pascal Bourguignon wrote:
> 
> > It's a little more complicated than that.
> 
> <snip>
> 
> Sorry to sound dismissive, but I've spent a lot of time on this
> discussion and I'm not going to devote any more to it.
> 
> Your statements of X terminology contradict what I've just looked up
> in  the OReilly books (though you may well be right) so any
> discussion about X  would probably involve more confusion.

I'm sorry  about that.   The point here  is to  stick with two  set of
terminology : OpenStep  and X, and to define  clearly the mapping when
needed.
 

> More importantly, what started as essentially a question of whether
> the  OpenStep pasteboard server was associated with a screen or a
> computer (nothing  whatsoever to do with X) seems to have become yet
> another pointless 'lets replace  OpenStep with X' thread.

That's not what I meant.  Please don't replace OpenStep with X.

My  point is  that the  pasteboard functionality  is dependent  on the
window  server used  (because  it must  integrate  with window  server
native applications), and  that it would be better  implemented at the
back-end level than  in a separate server, whatever  the window server
used.

In  the case  of  X and  xgps  (or X  and xdps),  that  means using  X
clipboard. In  the case  of a  pure DPS window  server missing  such a
clipboard  feature,  that  means  implementing a  specific  pasteboard
server like  gpbs, and  having the GNUstep  backend use  this specific
server. Note that a GNUstep on OPENSTEP 4.2 backend would just use the
native pbs server.


 
> The answer to the original question is that the pasteboard server is
> associated with the workstation on which an app is being displayed
> (though need not  necessarily run on that workstation).  A
> workstation corresponds closely to what the  Xlib programming manual
> calls a 'display', but *not* to what you say is a display in X
> terminology.

You're right.  I  elaborated my terminology from the  practice, but in
effect, the -display option permits  specify a display and optionaly a
screen to  :0 is the  display 0  ; :0.0 is  the screen of  the display
0. Moreover, while this is not imposed  by X, the XFree X server seems
to  be able to  run only  one display  (therefore here  we have  one X
server for one X display, hence the confusion I made).

Note that there  is probably a redundancy in  the X terminology, since
they seem  to just confuse X  servers and X displays.  For example, on
Xlib - C Language X Interface, page 7, they write:

     2.1. Opening the Display

     To open a connection to the X server that controls a display, use
     XOpenDisplay.


Logical.  I would  have  use  XOpenServer, but  that's  just me...  So
perhaps the fact  that all known X servers manage  only one display is
understandable, and my confusing of X display and X screen too.


So you can replace all occurence  in my previous messsages of X server
by X display and of X display by X screen. Thank you.

Then, the clipboard is managed by  the X server, but attached to one X
display.

You can check this with:

  startx xterm -display :1 -- `which Xnest` :1 -geometry 1024x768

and try X copy-and-paste between X apps in :1 and :0 and back.


> Applications should really (ie this is what NeXTstep did) use a
> command-line argument to determine which host they display on (and
> hence where the  pasteboard should be), but this is not yet
> implemented in GNUstep.

What do you  mean it's not implemented in GNUstep?  I'm just running a
small GNUstep application on another Xnest display:

[pascal@thalassa Apps]$ DISPLAY=:1.0 ooestimate.app/ooestimate 
Xlib:  extension "MIT-SHM" missing on display ":1.0".
Jan 10 00:10:56 ooestimate[23685] No font cache available - building new one - 
this may take several seconds (or minutes on a slow machine with lots of fonts)
X Error of failed request:  BadAlloc (insufficient resources for operation)
  Major opcode of failed request:  45 (X_OpenFont)
  Serial number of failed request:  1812
  Current serial number in output stream:  1813
Jan 10 00:11:24 ooestimate[23685] Error - font cache doesn't exist

(In spite of these errors, the applications actually works on the other screen).


And even on another host without any GNUstep stuff on it:

[pascal@thalassa Apps]$ DISPLAY=galatea:0.0 ooestimate.app/ooestimate
Jan 09 23:01:22 ooestimate[3223] No font cache available - building new one - 
this may take several seconds (or minutes on a slow machine with lots of fonts)

and it works perfectly well! And  that, with a GNUstep 0.6 of some six
months ago.

(By the  way, quite  funny to see  it in  twm, with the  menu "Window"
disappearing  everytime  the  pointer  moves out  of  the  application
windows.

Adding the handling  of a X -display argument  would just be syntactic
sugar.



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