Re: NSPasteboard on X, what to do?

[Björn Gohla]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 09 January 2002 11:51, Richard Frith-Macdonald wrote:
> On Wednesday, January 9, 2002, at 09:53 AM, Robert Slover wrote:

> > So I had always assumed that in a multi-screen environment (Xinerama?)
> > there
> > was still only one DISPLAY variable per user session.  If that
> > assumption is
> > correct, that seems to be the thing to group by, and in that case I
> > don't see why
> > there's anything special to be done to support multiple screens.  It
> > seems like
> > each backend should have some idea of what a user session key might be,
> > for
> > X it is DISPLAY, and the pasteboard server should be set up uniquely per
> > session key.  If my understanding is naive, please correct me.
there are different ways of setting up a multi monitor x-window system. 
xinerama allows you to turn several monitors into one logical x-display with 
windows streching across several screens, the viewports can even overlap. 
this gets you in trouble with window managers that can not handle 
non-rectangular displays if the resulting x-display is not rectangular 
(probably most wms). on the other hand you can turn several monitors into 
seperate logical x-displays. i have two monitors and that yield two displays 
:0.0 and :0.1 . in this setup i can not have windows straddle multiple 
monitors, and dnd is not possible between screens at least not with kde apps. 
of course all app running under x or have been started from an x app have 
their DISPLAY variable set accordingly, so in that sense i have several 
several DISPLAY variables on my machine. 
additionaly i do run Xnest occasionally to test applications with a different 
window manager. i can select text in my main session and then work on it with 
a gnustep app running in the xnested session, although having started one 
pasteboard server seems to suffice.


> Sounds very reasonable to me ... at the moment there is one pasteboard
> server
> per machine ... but I have never actually encountered a case where there
> is was
> not a one to one mapping between machine and DISPLAY (as described
> above).
>
> I'm sure there must exist some setups (corporate/academic?) where they
> have mainframe
> systems with multiple DISPLAYs, but I think they must be pretty rare.

see above

> So ... we should probably modify stuff as follows -
> 1. Extend the pasteboard server so we can tell it to advertise itsself
> to the network
> using a name corresponding to the display it is started for.
> 2. Modify the NSPasteboard class to get it to connect to the correct
> pasteboard rather
> than using the default name on the local host.
> 3. Define a user default to specify which host/DISPLAY an app is
> supposed to use and/or
> an API for the backend to tell the frontend about this.

how about having gnustep apps use an environment variable PBSERVER along the 
lines of the DISPLAY variable? it would be propagated into remote ssh 
sessions, and you can have your session startup script initialize it for you 
if you work in an environment where the pbserver does not run on the same 
machine as either the display server or the application. if the variable is 
not given apps would simply turn to localhost.

btw, kde gets around these problems simply by using only x window mechanisms 
to make applications talk to each other, so they are interconnected by virtue 
of being clients to the same x-server. 

it seems to be the most sensible approach to have one pasteborad server per 
user session, wich is uniquely identified by the x-server name (ie everything 
before the dot). i would not consider the usual pasteboard explicit enough as 
a means of inter-user exchange. i could imagine it be useful in some 
situations where users need to pass objects bewteen each other quickly and 
often to have a dedicated public pasteboard on the local network represented 
for instance by a miniwindow that things can be dropped into and dragged from.

i hope this was not too confusing.
- -- 
- --------------------
The Internet was invented as a highly dependable, high-speed, distributed, 
secure, and powerful network so that in the event of a nuclear crisis, 
military officials would always have access to pornography.
pub  1024D/834F4976 2001-01-07 Björn Gohla (Wissenschaftler, Weltbürger) 
<b.gohla@gmx.de>
     Key fingerprint = 9FF4 FEDA CCDF DA0E 14D5  8129 6C14 3C39 834F 4976
sub  1024g/29571FE2 2001-01-07
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8PJDlbBQ8OYNPSXYRAvq/AKC1Z9Ope1B2LozOVDjDRLm73nSRTACfTAl0
35D+lSIi+POtxfWrK9AlnRE=
=tcG+
-----END PGP SIGNATURE-----