[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSPasteboard on X, what to do?
From: |
Dennis Leeuw |
Subject: |
Re: NSPasteboard on X, what to do? |
Date: |
Thu, 10 Jan 2002 08:12:03 +0100 |
Hi all,
The machine, and I talk about the hardware (harddisk), that has a GNUstep
app that you want to run also has gpbs installed. If that is started at boot
time, we have a gpbs server running that is machine dependend.
If every user get's a temporary database in his/her home dirctory that
records all cuts and the gpbs server it is stored on, you could then paste
it in every app the user is running.
Downside is the network traffic...
Dennis
Richard Frith-Macdonald wrote:
> 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.'
>
> > 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.
>
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> http://mail.gnu.org/mailman/listinfo/discuss-gnustep
- Re: NSPasteboard on X, what to do?, (continued)
- 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, 2002/01/09
- Re: NSPasteboard on X, what to do?,
Dennis Leeuw <=
- 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