| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 802.1 | "xcons" from MIT release | 32956::graham | Mind Terrorist... | Thu May 18 1989 20:26 | 6 |
|
You may a get some good ideas on how to write such client code if you
can get your hands on the MIT sources for xcons.
Kris..
|
| 802.2 | | PSW::WINALSKI | Paul S. Winalski | Fri May 19 1989 00:14 | 5 |
| The session manager does this by keeping a DECterm pseudo-terminal around, but
not mapping its window on-screen.
--PSW
|
| 802.3 | | KOBAL::VANNOY | Jake VanNoy | Fri May 19 1989 17:27 | 7 |
| Almost. It uses the pseudo-terminal facility included in DECwindows for
the DECterm application. It doesn't use any DECterm facilities.
The pseudo-terminal facility isn't documented.
jake
|
| 802.4 | How can customers manipulate broadcasts/icons? | 42469::HARVEY | Witty little message in profile | Tue May 23 1989 11:31 | 29 |
| >The pseudo-terminal facility isn't documented.
That's a tad unfortunate. A customer of ours needs to manage 6 -7
clusters running multiple applications. They intend having four
set host terminals on a workstation, each logged into a cluster. They need
to trap any I/O (but assume broadcasts for the moment) to the virtual terminals,
pass this to a program (through a mailbox), and the program will then interpret
the messages, and change the colour/shape/message of ICONs to indicate that
operator activity is required - a little like the "New Data" info on the VWS
icons, but taken one step further. I realise that there is some similarity to
the VCS 1.3 offering - I'm currently investigating this, but in the mean time
is anybody working on anything similar?
Does this sound feasible using SUPPORTED facilities? My best idea so far is
for the broadcasts to be sent to a mailbox, (one for each terminal)and the
detached process to be notified of new broadcasts. The main issue is displaying
dynamic icons in the icon box a la mail, but slightly more sophisticated.
As a part of this, it is also a requirement for the terminal screen to be
positioned, one in each corner of the screen so that they are totally visible
to the operators. Is it possible to influence the position of DECterms when
created by the session manager (I doubt it..).
Any ideas?
Thanks in advance,
-Ralph-
|
| 802.5 | | ORPHAN::WINALSKI | Paul S. Winalski | Wed May 24 1989 01:52 | 12 |
| Regarding getting broadcasts, I think you can do this by creating DECterms
from within your application and assigning a channel to them with an
associated mailbox. I think the DECterm won't be mapped to the screen until
you actually do a $QIO write to it (that was the way that VWS emulated
terminals behaved, anyway). Failing that, there are pseudo-terminal drivers
available for VMS through DECUS. VMS has recognized the need, both DEC-
internal and customer, for a supported, documented pseudo-terminal facility
and is working out how best to meet that need. No commitments as yet to
anything, though.
--PSW
|
| 802.6 | | 56733::MESSENGER | Bob Messenger | Wed May 24 1989 11:28 | 26 |
| Re: .4
>As a part of this, it is also a requirement for the terminal screen to be
>positioned, one in each corner of the screen so that they are totally visible
>to the operators. Is it possible to influence the position of DECterms when
>created by the session manager (I doubt it..).
You can't control the position of created DECterms when they're created
by the session manager (not on a per-window basis, anyway), but you can
do it using DECwTermPort, which is the subroutine that the session manager
calls to create DECterm windows. See note 289.1 in the DECterm conference,
HANNAH::DECW$DISK:[PUBLIC]DECTERM. If this were an internal project I'd
suggest using CHILD. A supported CHILD equivalent is "in the works", but
probably won't be ready in time to help your customers.
Re: .5
>I think the DECterm won't be mapped to the screen until
>you actually do a $QIO write to it
No, that's not how it works (it's an interesting idea, though). One of the
ways you can start up DECterm, for example, is without a process: you don't
get a Username: prompt until you type a return.
-- Bob
|
| 802.7 | | 32148::KLEINSORGE | Toys 'R' Us | Wed May 24 1989 12:24 | 11 |
|
The VWS mechanism was done in the port driver and was mostly designed
to allow the owner of the terminal (in a "process address space" meaning
of "owner") to be the process that wrote to it rather than the terminal
that created it (by call or by cloning the template device via Assign).
When the VWS$EMULATOR process existed (it no longer does), this was no
longer needed since the process context would not dissapear - as the
deferral is not needed by DECterm - but it's properties (allowing setup
of a number of terminal properties prior to creation) are still handy.
|