Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!purdue!decwrl!shelby!unix!quintus!arisia!sgi!shinobu!odin!fudge!karlton
From: karlton@fudge.sgi.com (Phil Karlton)
Newsgroups: comp.windows.x
Subject: Re: Sending a string to another Window using DECWindows
Keywords: X, DECWindows
Message-ID: <189@odin.SGI.COM>
Date: 5 Jul 89 23:57:32 GMT
References: <9228@phoenix.Princeton.EDU>
Sender: news@odin.SGI.COM
Distribution: na
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 36

In article <9228@phoenix.Princeton.EDU> samuels@phoenix.Princeton.EDU (Mark E Samuels) writes:
>Is it possible in X or Decwindows to send a string to the window of
>another client and have that client read the string as if it had been
>typed from the keyboard?

Well, anything is possible. Some things are just easier or more effecient
than others.

>For example, if a command line based program
>that knows nothing about X  windows is running in a terminal emulator
>window(call this client #1) and client #2 is a program that wishes to
>send client #1 a command, could client #2 send a string to client #1 and
>have client #1 read it as if it had been typed into it's command window?

One way that will probably work is to cons up some KeyPress events and
SendEvent them to the terminal emulator window. Unless you are careful
(or have some a priori knowledege about the encodings supported by the
terminal emualator) this tack will not be very portable to an international
environment. There may also be a performance penalty of having to fake
passing an string as a sequence of keyboard events. The terminal emulator
will have to have been configured to not strip out events with the
"SendEvent" bit turned on.

Another choice would be to SendEvent a ClientMessage event that specifically
meant to "insert string". The current ICCCM does not define such a
ClientMessage. (In fact there is no section on peer-to-peer communication
using ClientMessages.) When that does happen, no doubt versions of
ClientMessages will be defined that include the "string" internal to the
message as well as ones that indirect through a property.

If it is possible that the user will be directing the transfer of information,
then it should be fairly straightforward to use the standard Selection
mechanism and have the terminal emulator "pull" the value from client #2
rather than "pushing" it when the emulator least expects it.

PK