Conference bulova::decw_jan-89_to_nov-90

Re: .0

That's interesting; it would seem to indicate that DECterm's VT240 ID isn't
the same as a real VT240's ID, which would be a bug in DECterm.  Please submit
a QAR to make sure this problem gets tracked.

Another possibility is that the application is looking at the secondary ID,
rather than the primary ID.  The Terminal ID selection in DECterm only
affects the primary ID; DECterm always "tells the truth" when an application
asks it for its secondary ID.

To help track this down, it would help if you SET HOST 0/LOG before running
the application, so that we can see what escape sequence the application
might be sending to DECterm to request the terminal ID.

Yet another possibility is that the application is looking at the terminal
characteristics it reads from the driver.  In that case we'd need to find out
what specific characteristic or characteristics it is looking for.

				-- Bob

I've heard that VT340 emulation under DECwindows doesn't offer mouse support,
though I haven't got an application on my workstation to test the assertion.

First off, how does one explicitly trigger VT340 emulation, as opposed to
setting the device type to VT300?

Second, is this report true, and if so, is there any intent to rectify this?

Reason for asking: I know of several vendor applications which are targeted
explicitly for VT340 use, and do use the mouse. VT340 emulation is their most
obvious bridge to the future; it'll be a while before all VT340s are replaced
by X terminals, I'm afraid.

Re: .2

DECterm does support VT34-style mouse support.  It's there by default; there's
nothing you have to do to enable it other than send the usual ReGIS commands.
However, DECterm doesn't support customizing the cursor shape; it uses whatever
input cursor has been defined for the workstation.

				-- Bob

Bob- since I posted my note, I've found the DECterm conference, and indication
that the graphics cursor is not supported by DECterm, and won't be for the
foreseeable future. That's really the issue with the applications I'm thinking
of; for instance, one selects a zoom area by using a rubber-band cursor to
enclose the area, and the application obtains the cursor and draw coordinates
to register the desired rectangle.

Can you suggest any way to "fudge" this or similar applications without
substantial recoding? The problem is, many customers want to transfer operations
over to VAXstations immediately, running existing VT-340 applications, and
migrate to "pure" DECwindow/Xwindows applications at whatever rate they become
available. Vendors don't want to invest nontrivial effort into fudging code
which is destined for obsolescence, yet customers can't wait for the real
time required to produce "proper" X-based versions of their products.

Another issue involved is more long-term. VT340s may in fact "live" for quite a
while in applications such as factory-floor display (which is the application
I'm thinking of in particular), because of the focus on cost per seat.
Applications involving "high-end" (editors, process planners) and "low-end"
(viewing) users are best run on a DECwindows workstation during the preparation
phase, with a VT340 window displaying the end result WYSWYG. Display currently
works fine, as it merely involves sixel and REgis capabilities which are
handled by DECterm. It would seem that sufficient revenues are at stake to
warrant extension of DECterm's emulation to as high a level as possible.

Re: .4

>Can you suggest any way to "fudge" this or similar applications without
>substantial recoding?

Not really.

>It would seem that sufficient revenues are at stake to
>warrant extension of DECterm's emulation to as high a level as possible.

I agree, but unfortunately there are no easy answers.  There should be more
people working on DECterm, but at this time of shrinking headcounts it's
not clear where those people would come from.

				-- Bob

Thanks for the lowdown. I'll pass on the status to the CMPs I know of that "need
to know," and refer them to the appropriate folks if they wish to twist any
arms on the subject. For the time being, howver, at least they'll know what they
have (and don't have) to work with.