[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 20:53:42 +0100 (CET) |
These questions are also related to the configuration of the system.
I agree to call 'workstation' the set of element a given person uses.
In that case, when we're using GNUstep on X, let's map a workstation
to a given X-server.
Note that nothing in X prevent a given person to use various X servers
at the same time. Only that an atomic inter-relation is always done
between one person and one X server.
My point here is that there are configuration objects and sematics in
X that allow the administrator of a X system to configure it to match
a given setup (set of hardware and software) to a given usage (set of
persons using the system in a set of roles). Therefore, we could
profit from this confugurable layer and map GNUstep concepts on X
concepts in a meaningfull and useful way.
Otherwise, we will need to configure the GNUstep system too and this
may lead to confusion and incoherencies.
I'm supposing that one GNUstep setup will only use one kind of backend
(in the case at hand, only X xgps backend). Do we want to allow the
configuration of a GNUstep application running with two NSScreens one
on a DPS server and another on a X server, thus running with two
different backends at the same time?
So, in the case where we have a system made of X servers, pure X
applications, and GNUstep applications with a single X backend, I say:
Let's say that we'll map a workstation to a X-server session.
Let's say however that we'll agree to have one GNUstep application
open windows on NSScreens mapped to various different
X-server. (*)
Let's say that we'll map NSPasteboard to the set of X clipboards
in the X servers the application is (indirectly thru NSScreen)
using.
This has the advantage of:
- not needing any configuration other than the X-server
configuration, and the specification of the X-servers a given
application may use (to gather the NSScreens on various
X-servers).
- being integrated with the pure X applications.
- being able to run GNUstep application in any X configuration as
complicated or as simple as it can be.
(*): Note that this means that one application may have windows on
different workstations, that it may receive events from different
window servers (X servers)! Is there anything in the X backends of
GNUstep that support that, or at least that don't prevent that? Does
the front-end consider the agreagation of all X servers as one window
server?
In the case of emacs with windows in different X-servers, that is,
when a single emacs process is used on two different workstations,
emacs manages one cursor (or insertion point) per
workstation. Therefore, it's possible for two persons to edit the
same buffer, inserting text at two different places in the same
buffer at the same time. Well, same time modulo the fact that when
emacs enters a 'modal loop' (like in the mini-buffer) on one
'workstation', the other editing is suspended (input characters are
queued). That is, emacs is not multithreaded, but is able to work
with several window server at the same time.
Of course such a feature is very usefull for some kind of software
(think groupware).
We could map a GNUstep 'workstation' to something different than a
X-server, but to do that we would need a configuration file describing
underlying elements and the linking of those to the GNUstep
workstation (like XF86config). I'm not sure it's worth the work.
Of course, the code in the NSPasteboard back-end is specific to X, and
it means that another back-end will have to implement its own
NSPasteboard slice.
But implementing a general pasteboard system poses the problem of not
being integrated with the underlying window server. From a political
and strategic point of view, it's better to be well integrated to
whatever window system we happen to be running on.
My view is that the pasteboard server existed in NeXTSTEP only because
it was not implemented into the DPS window server. Problems with a
separate pasteboard server: what to do when there are several
applications running with different UID? On NeXTSTEP, since both
applications will display on the same window server, even when there
are two screens, a copy-and-paste between both application will work
as expected, and since it's impossible to configure two workstation on
NeXTSTEP systems, there's no problem. But on other systems, and in
particular with X window servers, it's possible to configure two
different workstation on a multi-header host, with, logically, two
X-servers, each with its own clipboard, allowing two persons to use
the system at the same time. Now a GNUstep pasteboard server will have
either to manage two separate spaces, or we will need to launch one
pasteboard server for each workstation (person). Actually, we would
have to reimplement all the clipboard management of the X server into
the GNUstep pasteboard server to be able to handle properly this kind
of configurations.
Even with a DPS window server, we could have multi-workstation
configurations. I'm not sure that the NeXTSTEP pbs would behave
gracefully in that kind of configurations.
That's why I think that here, it would be better to implement these
features in the back-end and in a window server specific way. If we
need a separate pasteboard server for the window server that don't
have one, ok. But for those like X, MS-Windows, Aqua that have one,
it's better to use their specific clipboard.
And in anycase, even if we had a separate pasteboard server, in the
case of the X backend we will need to comunicate with the X clipboard
anyway to be compatible with pure X applications.
> Date: Wed, 9 Jan 2002 17:55:44 +0000
> From: Richard Frith-Macdonald <richard@brainstorm.co.uk>
>
>
> On Wednesday, January 9, 2002, at 04:40 PM, Pascal Bourguignon wrote:
> >>> t about the other pasteboards?
> >>
> >> I think they should be using the pasteboard server of the *machine*
> >> to which they are displaying. So you could cut and paste between
> >> apps on any screen attached to that machine. This model assumes
> >> that every screen is attached to a machine - I know that that is
> >> not 100% the case in X, where a screen may be a dumb X server, but
> >> I'd suggest that in such a situation it would be beast to designate
> >> some real server (where a pasteboard server process can run) as the
> >> owner of that screen.
> >
> > The point is that the host where X server is running is not
> > necessarily a GNUstep host, and most probably will not run gpbs. Think
> > X terminal here. So we need to use the X server pasteboard.
>
> Or run the pasteboard server for that X machine on one of the machines
> where GNUstep *IS* running (this would be trivial).
>
> > I don't
> > know of any X server not implementing the X pasteboard, even when
> > running in a X terminal. I can't see any reason why not to use it.
>
> Well, we do use it ... for communication with X apps. The reasons to
> only use it for that are: portability, complexity, efficiency.
> Using a native GNUstep pasteboard is portable.
> Massaging X APIs to fit the OpenStep model is non-trivial!
> Using the X pasteboard for everything we would need to duplicate loads
> of stuff we get for free.
>
> > I'm wondering what use gpbs may have... Why do we need to designate
> > some "real?" server? Do you mean "host" here? The owners of the
> > screens (displays) are the X servers of course.
>
> There are times I hate living in an X-centric world, and have to remind
> myself that people really are asking quite reasonable questions. Despite
> using X apps daily, and having done quite a bit of programming with it,
> I just don't think the X way. I'm still more familiar with alternative
> worldviews :-)
>
> I was talking about where to run a pasteboard server, not where to run
> the X server. From that point of view, the 'ownership' of the screen
> has *nothing* to do with X.
>
> By 'designate', I merely mean select. That selection could be done
> in many ways -
>
> eg.
> We could have a single powerful server machine running GNUstep
> pasteboard servers on behalf of a bunch of X terminals which can't
> run them locally. If the users of those X terminals used GNUstep,
> and executed their apps on the same big machine, the result would
> be a much more efficient system as the cut and paste and drag and
> drop traffic would all be on the one machine rather than having to
> go to and from each X terminal.
>
> We could just have any GNUstep app start up the pasteboard server
> for an X terminal the first time it tries to access the pasteboard
> (as happens in the current code).
>
> We could set up a mixed policy of some sort.
>
> >
> >>>> 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)
> >>>
> >>> Exactly! this is the problem.
> >
> > Be carefull. User is a unix notion = UID. Let's speak of human being
> > in front of the work stations as "persons". Then we may have two
> > persons in front of two keyboards (X-inputs) and two screens
> > (X-displays) connected to the same X-server.
>
> An X display is apparently *not* a screen.
> From the XLib manual ...
> 'a display is defined as a workstation consisting of a keyboard, a
> pointing device suck as a mouse, and one or more screens.'
Well, I may be mixed here. I'm using the terms as used in practice in
the programs and configuration files. This may differ from the
theorical names found in the documentation which I haven't read for
several years.
> > Should they share the
> > same pasteboard in the same X-server in that case? I say yes. I say
> > that if one want them to have different pasteboard, then configure two
> > X-servers each with a different X-display and X-keyboard. To configure
> > both screens as two X-displays on the same X-server is usefull only
> > when one person will work with both keyboards and displays.
>
> I think we are all happy with that.
>
> Only I'm using the term 'workstation' because I'm not restricting my
> thinking to X (and because 'machine' turned out to be too confusing).
>
> One pasteboard server per workstation. The pasteboard server to usually
> (but not necessarily) execute on the workstation.
>
> >>>> 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.
> >>
> >> I was being stupid because I allowed myself to be trapped into the
> >> model you presented where machines and screens are separate ... the
> >> solution is trivial if you say that each screen is associated with a
> >> machine.
> >
> > That's not the case. You may have several X-server running on one
> > machine, each with several X-displays to various persons.
> >
> > +-------------------+
> > | Machine 1 |
> > +-----------+ | |
> > o |Display 11 |-\ | +-----------+ |
> > /O\ +-----------+ \-|--| Server 1 | |
> > / \ +-----------+ /-|--| | |
> > |Display 12 |-/ | +-----------+ |
> > +-----------+ | |
> > | |
> > | |
> > | |
> > +-----------+ | |
> > o |Display 21 |-\ | +-----------+ |
> > /O\ +-----------+ \-|--| Server 2 | |
> > / \ +-----------+ /-|--| | |
> > |Display 22 |-/ | +-----------+ |
> > +-----------+ | |
> > +-------------------+
>
>
> However, I was using 'machine' in the sense of 'workstation',
> which corresponds to an X display, or a NeXTstep host rather
> than a backend server.
>
>
>
--
__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?, 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
- Re: NSPasteboard on X, what to do?, Dan Pascu, 2002/01/10
- Re: NSPasteboard on X, what to do?, Pascal Bourguignon, 2002/01/11
- 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 <=
- 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?, 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