[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSPasteboard on X, what to do?
From: |
Björn Gohla |
Subject: |
Re: NSPasteboard on X, what to do? |
Date: |
Wed, 9 Jan 2002 19:50:08 +0100 |
-----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-----
- NSPasteboard on X, what to do?, Willem Rein Oudshoorn, 2002/01/08
- Re: NSPasteboard on X, what to do?, Dennis Leeuw, 2002/01/09
- Re: NSPasteboard on X, what to do?, Richard Frith-Macdonald, 2002/01/09
- Re: NSPasteboard on X, what to do?, Wim Oudshoorn, 2002/01/09
- Re: NSPasteboard on X, what to do?, Robert Slover, 2002/01/09
- Re: NSPasteboard on X, what to do?, Richard Frith-Macdonald, 2002/01/09
- Re: NSPasteboard on X, what to do?,
Björn Gohla <=
- Re: NSPasteboard on X, what to do?, Dan Pascu, 2002/01/10
- Re: NSPasteboard on X, what to do?, Björn Gohla, 2002/01/11
- Re: NSPasteboard on X, what to do?, Richard Frith-Macdonald, 2002/01/09
- Re: NSPasteboard on X, what to do?, Wim Oudshoorn, 2002/01/09
- Re: NSPasteboard on X, what to do?, Richard Frith-Macdonald, 2002/01/09
- Re: NSPasteboard on X, what to do?, Martin Brecher, 2002/01/09
- Re: NSPasteboard on X, what to do?, Pascal Bourguignon, 2002/01/09
- Re: NSPasteboard on X, what to do?, Richard Frith-Macdonald, 2002/01/09
- Re: NSPasteboard on X, what to do?, Pascal Bourguignon, 2002/01/09
- Re: NSPasteboard on X, what to do?, Jeff Teunissen, 2002/01/10