I well realize that the QCTerm topic is becoming tiresome to a number of the
people on the list. Nonetheless, let me sew up a few dangling threads.

========================================

THE X-PHILES

Erik Vistica writes:

> Side note...I am fairly new to using a PC as my desktop device (used to
>  use a 9000 workstation - what can I say? I work for HP :-) The cut/paste
>  in X-windows was wonderful, the PC way is intolerable.
>
>  In X-windows:
>
>  click/drag  does the 'cut' (copy actually).
>  click mouse button 2 (or 3 depending on the appl) to paste.
>
>  No need to touch the keyboard or menu pull-downs at all!
>
>  Any chance you could implement the X-windows method into QCTerm too Wirt
>  (like you have nothing else to do :-) Be the first on your block to
>  bring PC Windows cut/paste into the early '90s.

We can't do it in the same manner as X-windows, simply because it's
impossible to make one horse serve two masters at the same time. The mere act
of "selecting" text under X-windows apparently puts the selected text into
the clipboard, and that isn't the way Windows or Macs work. Although Erik's
suggestion has been suggested to us several times before, it must be
remembered that QCTerm is first and foremost a Windows program. Maintaining
consistency is of the utmost importance.

However, we have discussed among ourselves here a way of doing something very
similar. Indeed, we're putting it together now to see how well it works. In
this modified X-windows copy-and-paste, the following behavior is being
implemented:

     o a left-mouse click, in any QCTerm window, will establish an initial
cursor point, moving the cursor to that point. Holding the left button down
and dragging the cursor will "select" the text. Releasing the left-button
will establish the end point of the select operation. This is standard
behavior.

     o a right-mouse click will then absorb (copy) the currently selected
text in the currently active window into the clipboard.

     o you may then move to any point in a QCTerm window and left-click to
again reestablish a new cursor point. If you stay in the same window, this
operation will also clear the previously selected text in that window (which
is also standard behavior). Once there, a right-click will paste the text
onto the screen, beginning at the current cursor point.

After we independently devised, with great pride I might add, this
X-windows-like copy and paste method, we were surprised to find that some
Windows programs have already implemented a very similar method. The programs
that act in much the same way are Notepad, MS Word 97 and AOL (IE and
Netscape don't). Although the programs that operate in this manner do require
one more click than the way we're proposing, we may go ahead and do it the MS
way, simply because the right-click menu that pops up is self-explanatory.

Take a look at the right-click method in Notepad for the slightly alternate
behavior. Comments, as always, are welcome -- although I'm sure that most
people on this list would prefer "the less clicks the better." The question
is one of consistency (for a not-yet stable "standard") vs. user speed.

========================================

TERMINAL VELOCITY

Richard Gambrell wrote:

>  Just the other day, one of our users asked if we show an email address
>  on the terminal screen, for example a display of a student's address, if
>  we could arrange it so they could just click it and open up an email
>  message to send (just like a web browser).  I immediately thought of
>  QCTerm's potential here.
>
>    In Reflections, I think I could arrange a button to click that would
>  extract the email address from the screen, but it would be much more
>  generally useful if the terminal actually recognized URL syntax itself
>  and handed it over to the default web browser.
>
>    Of course, we could provide a way for the user to compose the email
>  message through the terminal screen (not too bad an idea if we had the
>  full screen editor to use), but why duplicate what the web browser or
>  email program does well already (I can think of reasons like contact
>  tracking and such, but these are not always needed)?
>
>     I've now thought of a bunch of different uses for this idea, mostly
>  for clicking on an html URL, so  I hope you've got it in mind to bring
>  this to QCTerm soon also.

We have given some significant thought to this request, but we've decided
against implementing URLs the way that Richard suggests, where the URL would
appear in the terminal's text buffer.

While it's possible to do what's been suggested (indeed, anything's
possible), I am extremely jealous of maintaining QCTerm's speed, particularly
on scrolls. A terminal is not a browser. A browser paints its image as a
static picture onto a canvas; a terminal's buffer, by contrast, is an
extremely dynamic structure, where any line or group of lines can change,
moment to moment. If we had to scan every line for HTTP tags -- which would
probably be extremely rare usage -- before we displayed it, we would likely
slow every other user down dramatically.

The best way to accomplish what Richard wants, we believe, is to put buttons
onto the screen, as part of the background wallpaper. If you are familiar
with the Equater! demonstration, imagine buttons down the left hand side of
the screen, one of which might say "E-mail Student".

[If you aren't familiar with the demonstration, telnet to 209.181.113.217,
sign on as:

     :hello yourname,demo.qcterm

and type:

     :eq

to see the screen.]

The importance of the Equater! example is that the "terminal window" has been
offset to the right and down a bit. More importantly, the code that is
running is "legacy" code, written 15 years ago and completely unmodified for
this example -- and that would be no small benefit in Richard's case also.

The HP3000-resident program could easily ask for a terminal identification.
If the terminal is a copy of QCTerm that is sufficiently new, a background
wallpaper, including buttons, can be transmitted before the legacy program is
initiated. If the terminal is not QCTerm, the user would see what he or she
has always seen in the past, without any modification to the program.

However, when the HP3000 is talking QCTerm, buttons can be defined on the
fly. If the student has an e-mail account, an "E-mail the Student" button can
be instantly displayed and made to launch the default PC e-mailer program.
The same would be true if the student had a home page somewhere; a "Student
Web Page" button could be displayed. And if the student's records indicated
neither, the buttons could either be grayed out or not displayed at all.
Because of the manner by which the van Gogh mode in QCTerm is put together,
these changes can be made to occur instantaneously. Indeed, it's possible,
based on the data you might find in a database, to change the color of the
background screen, bring up a different set of logos, display the subject's
picture, etc. in either the area surrounding or behind the terminal display
area.

========================================

SINGLE-CELL BEHAVIOR

One person wrote me privately the most important of all of the questions we
receive about QCTerm:

> I've a couple of fairly serious questions about QCTerm.  The first is, how
> soon will pick lists and suchlike be available.  The second is more
> significant  yet.  That is, when all such things are in, will it be
> straightforward to allow data to be entered in any order the user
> prefers.  I'm already thinking of ways it could happen, but I'd like
> your thoughts on the matter.  I don't want to go to block mode.
> I want, for instance, for a user to be able to select the id-number
> box and enter an id number and immediately have the record
> pulled up and then click on spot to enter educational subsidy,
> change that number and have the expected cost for the semester
> recomputed immediately, click on the spot for estimated food,
> enter a number there, be told that the number is out of range
> --that sort of thing.
>
> We're under a lot of pressure in this project.  Administration is intending
> to replace the current "administrative data" system this next summer.
> At best they are intending to buy a third-party 3000-based package,
> at worst the 3000 gets scrapped.
>
> That range isn't good news.  We in IS have to be
> able to demo, within two months, a product which will compete with
> the third-party apps. That's not a lot of time.  My boss, who isn't a
> 3000 man (but is a decent guy nonetheless ;-), has been talking
> about going client-server.  New development on the 3000 would stop
> and it would essentially become an ODBC database server. All new
> development would be done in Visual Basic, Delphi or some such,
> using ODBC to get to the data.
>
> His strong card is that the development tools for that sort of thing
already
> exist.  If we go with a thin-client implementation, we'll have to go with
> something that is currently beta or else roll our own.  We meet again on
> Monday to hash it some more and I'm still looking for solutions.

What this correspondent wants to do is precisely what we're designing the van
Gogh-based forms mode in QCTerm to do. There will be two ways to use the
forms mode in QCTerm. In that regard, please understand that when we're in
the forms mode, we've essentially left behind the Reflection-like terminal
emulator; we're using a whole new construct now, one that is meant to be
extremely attractive -- and yet still maintain the interactivity of a
terminal.

If you want to review the kinds of screens that we're aiming at, please see
the figure in the middle of the webpage at:

     http://aics-research.com/qcterm/nextgen.html

While this form is relatively prosaic, in the sense that it is merely a tax
form, it is also indentical in many ways to the correspondent's questions.

Every active object (buttons, maps, text entry boxes, picklists, radio
buttons, and checkboxes) on a van Gogh forms page will be given a name by the
form's designer. If the designer chooses to make the forms page operate in
"page mode", the only time the values that are entered onto the page will be
transmitted to the HP3000 will be when the user presses a "submit" button.
Such a button would signal the HP3000 to read all of the cell values on the
page, as a whole.

The alternate behavior will be a "cell modify" mode. When a cell's value is
changed -- and only then -- will that cell's nametag and value be transmitted
to the HP3000. In doing this, the HP3000 can instantly check the value for
its legitimacy. More importantly, the program can instantly alter its
behavior, doing things such as reloading the values that make up a picklist
somewhere else on the forms page, or it can immediately update a graph on the
page, or it can do what the questioner asked above. The model that we've had
in mind is virtually identical: filling out a standard tax form, where the
total of lines 11, 12, 13, 14, and 15 be displayed on line 16. As the user
enters those lines, in any order, cell by cell, the total on line 16 will be
constantly updated by the HP3000.

We're putting all of the logical behavior on the HP3000 -- but that's
precisely where we believe it should be. We want the world's prettiest
screens, but we also want the world's dumbest client. Trying to make two
"smart" devices talk to each other is the first great mortal sin -- and it
breeds nothing but unreliablity and fragility.

In either mode, cell mode or page mode, you can very rapidly move from cell
to cell by either clicking on a cell, using the arrow keys or the tab keys or
the RETURN key. But if you are the cell mode, when you move to a new entry
cell, we will instantly memorize the current cell's value. When you leave
that cell, we will check to see if the current value is the same as the
initial value. If it is, we do nothing. But if it has changed, we then
transmit the new value (and its nametag) to the HP3000.

It's at that point that the HP3000 can either update other parts of the
screen, change pages, redraw the background, add or modify graphs, or reject
the entry by beeping the bell and putting the user's cursor back on the cell
with the unacceptable data value.

This form of data entry design will be exceptionally valuable if you're
relatively close to the host computer (I now consider anywhere in North
America to be "local"), but if you want to design software to be used equally
well by users in South Dakota, South Korea, and South Africa, then the page
mode will probably prove to be more satisfying, simply due to the distances
involved and the near 1-second delays associated with long-distance
telnetting. However, you're not locked into one mode or the other. You will
be able to switch back and forth, defining each form in your repertoire
individually.

On the matter of the second subject that was asked: "When will all of this be
ready?", we have about 20 developer organizations that are frequently asking
us that question, each telling us stories very similar to the one above
(which we take very seriously, btw). We're probably not going to be ready in
two months (whether those are Julian, Gregorian or Atmarian months). I would
think that four months is a much more reasonable estimate.

I can say that with some certainty because almost all of the behavior that
I've described above is now working. Indeed, one HP3000 software developer
has spent so much time on our 918DX that they've deduced the method by which
picklists and radio buttons work :-). They called the other day and said that
they were ready to release within a week or two their product that was based
on van Gogh. I was both greatly impressed and flabbergasted. I told them to
wait; we haven't even made up our minds about some very fundamental questions
regarding the implementation -- and everything is still subject to change.

While the terminal emulator portion of QCTerm is nice -- and it has to be
perfect -- it's van Gogh that is the item that will change people's minds
about the HP3000. A terminal emulator presents a face to the world that lies
somewhere between clunky and funky. In contrast, the van Gogh-based forms
mode is being designed to completely confuse the user. He or she won't know
whether or not they're running an application on the HP3000 or on the PC by
their feet. A form here will be highly interactive, very attractive, and yet
very easy to modify because ALL of the behavior will be driven from the code
resident on the HP3000.

========================================

Wirt Atmar