[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: |
Wed, 9 Jan 2002 17:12:05 +0100 (CET) |
> From: Richard Frith-Macdonald <richard@brainstorm.co.uk>
> Date: Wed, 9 Jan 2002 07:59:35 +0000
>
>
> On Tuesday, January 8, 2002, at 10:04 PM, Willem Rein Oudshoorn wrote:
>
> > - Every computer had ONE dedicated screen all for itself.
>
> No. A single application could have windows displayed on multiple
> screens on one machine. It could also display on another machine
> (though I'm not sure about using multiple displays on different
> machines).
Effectively. For example, with emacs one can do M-x
make-frame-on-display and have frames (X windows) on various
computers. I'm used to do it to continue work on laptop and back
without interrupting compiles and edits...
One could envisage a window manager that would integrate all the X
displays available on the LAN in one workspace, with the ability to
move windows from one computer to another on the fly.
> > On X this IS an issue. So in order to give some meaningfull
> > interpretation to the class description let's examine the
> > kind of NSPasteboards that are documented.
> >
> > The different NSPasteboards
> > ---------------------------
> >
> > * General Pasteboard (ordinary cut, copy paste operations)
> > * Font Pasteboard (support copy font, paste font)
> > * Ruler Pasteboard (support copy ruler, paste ruler)
> > * Find Pasteboard (active applications find panel)
> > * Drag Pasteboard (well, DnD of course)
> >
> >
> > So this clearly suggusts that the *all* is grouped by Screen.
>
> Not to me. I see dragging and cut-and paste as inter-screen operations -
> I want them to take effect wherever the mouse pointer is.
>
> In MacOS-X (essentially OpenStep) I routinely perform a cut on one
> screen, move the mouse to an app on my other screen, and paste into
> the second app. Similarly, I drag stuff from an app on one screen
> to an app on the other.
An important feature indeed.
> [...]
>
> > So I hope that someone can explain to me how we are going to
> > interprete the concepts `Application' and `all' in GNUstep.
>
> I'm pretty sure that the term 'application' is generally meant to
> describe a process which uses the AppKit.
>
> The aspect of this I've never been so happy about is the 'all'
> What about a multi-screened, multi-keyboarded machine with more than
> one user. Do both users share the same pasteboard server?
> I think ideally not. Each user would get their own server (to which
> they save data)
Well, in my emacs example, since emacs has windows on two displays
with two keyboards, two users could edit simultaneously two buffers in
the same emacs, or even, fight for edits in the same buffer. Of
course, since emacs is not multithreaded, there may be conflicts at
some times. But what I mean here is that users are not distinguished
by the X keyboard or even by the X server.
The only thing one can say about the user, is that he's identified by
the UID of the application process. If the user configures his
application to run with windows on other servers, other hosts with
other displays and keyboards, it's his responsibility to assure a
different person interacts with his applications in his name and in
synchronization with him.
In that kind of configuration I would expect a copy done at one
keyboard, to use the same pasteboard as used by a paste done at
another one.
Of course, if the copy were done at keyboard one in another
application, it would not go to the same pasteboard.
On another hand, with the following configuration:
+-------------------------+ +-------------------------+
| display 11 on server 1 | | display 12 on server 1 |
| +---------+ +---------+ | | +---------+ +---------+ |
| | win 111 | | win 112 | | | | win 122 | | win 123 | |
| | app 1 | | app 2 | | | | app 2 | | app 3 | |
| | user a | | user b | | | | user b | | user c | |
| | | | | | | | | | | |
| +---------+ +---------+ | | +---------+ +---------+ |
| | | |
| | | |
+-------------------------+ +-------------------------+
+-------------------------+
| display 21 on server 2 |
| +---------+ +---------+ |
| | win 214 | | win 212 | |
| | app 4 | | app 2 | |
| | user d | | user b | |
| | | | | |
| +---------+ +---------+ |
| |
| |
+-------------------------+
(Note that app 1, app 2, app 3 and app 4 may run on any computer of
the network).
Should win 112 and win 122 share the same pasteboard?
(Two windows of the same application on the same X server but on
different displays).
Should win 112 and win 212 share the same pasteboard?
(Two windows of the same application on different X servers.
I would expect drag-and-drop to function between all windows of the
same server.
Since I don't know of any window manager that integrate in a same
desktop displays on different servers, I would not expect
drag-and-drop to function accross servers. Anyway, this is not a
native feature of X, this would need some way of redirecting displays
from one server to another, or application level support to move
windows from one server to another. (Note that emacs frames created on
different servers cannot be moved to another server).
I would expect copy-and-paste between all windows of the same server
to work. That is, in particalar, the following sequence should be
possible:
- person at display 11 (server 1) copies data X from win 111 of app 1.
- person at display 12 (server 1) selects win 123 of app 3.
- person at display 12 (server 1) paste data into win 123 of app
3. Data X is pasted.
Now, while I would not expect copy-and-paste to work between different
X servers, data can still be pasted from win 214 into win 212 and thus
be available to app 2 on win 112 and win 123.
I think that allowing for a common pasteboard between win 214 and win
123, or even between 214 and win 122 just because it happens that
there is an application using both server 1 and 2 poses more problems
than the advantage it would offer.
Note however that these distinctions are not related to physical
disposition of screens and computers. We could have the three displays
mapped to three screens on the same desk, with both servers running in
the same computer, and our separating of pasteboard would be seen as
an artificial limitation. And each displays could be separated by
kilometers and three different persons could interact with the same
application app 2, and person at display 11 and person at display 12
would share the same pasteboard and this too would be viewed as a
problem. However these different physical configurations should be
handled in the configuration of the X servers: in the case where the
displays are not to be integrated in one desktop, the computer should
run two X servers.
So, my conclusion would be that what is needed is Grouping by X Server.
> > I think for the Pasteboard we can should settle on Grouping by
> > Screen
>
> I completely disagree ... I hope I have shown above that the advantages
> you list for doing this do not actually exist, while the disadvantage
> you supply for grouping by computer does not exist.
>
> > The pasteboard is part of AppKit/GUI so any application trying to
> > use the NSPasteBoard should have some concept of Screens. At the
> > moment AppKit only supports one screen, so multiple screens is no
> > problem. If GUI is going to support multiple screens per
> > Application, we need an extension of the NSPasteboard.
>
> We don't need any changes to support multiple screens ... where we
> will start to need to work on things is when we get multiple
> machines sharing the same screen. When that happens we need only
> ensure that the internals of the DnD system supply a pasteboard to
> the app which is connected to the correct pasteboard server. How we
> cope with a cut and paste operation between two apps on different
> machines (either on the same screen or on two screens of one
> machine) I don't know. I think this is the tricky case but it may
> be rare enough to ignore.
In the case of X windows, there is a pasteboard in the X server to
handle this case. Note that two GNUstep applications could have
windows on a X display in a X server that does not run GNUstep (no
gpbs process). However, we could still implement a communication
between these two application thru the X server. Perhaps without doing
anything more than for the communication between X applications and
GNUstep applications.
--
__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?, Pascal Bourguignon, 2002/01/10
- Re: NSPasteboard on X, what to do?, Dennis Leeuw, 2002/01/10
- Re: NSPasteboard on X, what to do?, Pascal Bourguignon, 2002/01/10
- Re: NSPasteboard on X, what to do?, Dennis Leeuw, 2002/01/10
- Re: NSPasteboard on X, what to do?, Pascal Bourguignon, 2002/01/10
- Re: NSPasteboard on X, what to do?, Pascal Bourguignon, 2002/01/11
- Re: NSPasteboard on X, what to do?, Dan Pascu, 2002/01/10
- Re: NSPasteboard on X, what to do?, Pascal Bourguignon, 2002/01/10
- Re: NSPasteboard on X, what to do?, Dan Pascu, 2002/01/10
- Re: NSPasteboard on X, what to do?, Jeremy Bettis, 2002/01/09
Re: NSPasteboard on X, what to do?,
Pascal Bourguignon <=
Re: NSPasteboard on X, what to do?, Wim Oudshoorn, 2002/01/09
Re: NSPasteboard on X, what to do?, Willem Rein Oudshoorn, 2002/01/10