[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference noted::hackers_v1

Title:-={ H A C K E R S }=-
Notice:Write locked - see NOTED::HACKERS
Moderator:DIEHRD::MORRIS
Created:Thu Feb 20 1986
Last Modified:Mon Aug 03 1992
Last Successful Update:Fri Jun 06 1997
Number of topics:680
Total number of notes:5456

184.0. "SMG Anyone??" by SANFAN::HAYESJO () Wed Dec 18 1985 19:22

I'm trying to write a program that will implement VAXStation-like windows
on a regular VT1xx or VT2xx class terminal using SMG routines.

What I'd like the program to do is create a window, associate it with
a subprocess, and let the user type in commands, run programs - basically
anything that they normally do (ie. be as transparent as possible).

The program will also 'trap' certain commands or function keys to allow
you to create another window, move the windows around, 'pop' windows,
select a window, etc.

A description of what I've done so far follows - but I'd appreciate any
ideas!

------------------------------------------------------------------------

(main_routine)
  create_window
  create_subprocess                 (subprocess)
    SYS$INPUT  -> mbx_1               executes LOGINOUT
    SYS$OUTPUT -> mbx_2        +----  DCL waits for command
  set read_attn AST on mbx_1   |             |
  set wrt_attn  AST on mbx_2   |             |
  hibernate                    |             |               
                               |             |
         (read_attn_AST) <-----+             |
           use SMG to get command from user  |
           check for user_command            |
             push/pop windows etc.           V
           write command to mbx_1 --> DCL executes command
           set read_attn AST on mbx_1        |
                                             |
         (wrt_attn_AST)  <-------------------+
           read subprocess output from mbx_2 |
           use SMG to format output          |
           set wrt_attn AST on mbx_2         V
                                      DCL/program waits for command
                                            
This arrangement doesn't acheive much transparency because the subprocess
is using mailboxes for input/output.  DEFINing sys$Input (in the subprocess)
to point to the user's terminal before sending commands to the subprocess
does acheive some transparency, but it wrecks havoc on the SMG windows.

Maybe mailboxes are not the way to go.  Any suggestions??

John Hayes, San Francisco SWS
(@SANFAN::HAYESJO)
T.RTitleUserPersonal
Name		DateLines
184.1TOOLS::STANThu Dec 19 1985 03:4216
I did something like this several years ago - it's called the
HACKSTATION-100.  One window only, though.  It uses the
remote terminal protocol to talk to the subprocess.
You're welcome to browse through the code; not sure if it
still works on 4.2.  Look in CLT::HACK$:[STAN.HACK]HACK2.EXE et. al.
You could move around your view in the window by typing keys
on the terminal.  It even handled things like CTRL/Y properly.
It also updated a time display while you are talking DCL in
your window.  I have no intention of getting back to this -
it was just a feasibility study.

Knowing what I know now, a better method than remote terminal
protocol these days would be to use the pseudo-terminal driver.
PTYs are definitely better than mailboxes.  With mailboxes you
won't be able to handle CTRL/C, CTRL/Y, CTRL/T, etc., nor
will you be able to run editors and certain display applications.
184.2SPRITE::MCVAYMon Dec 23 1985 10:5218
I'm working on a similar program at the moment, but with different windowing
goals.  It will allow the user to create "mini-programs" (technically called
objects), and they are authomatically placed in boxes (windows) when created.
The user can move these things around and string them together to create
programs, using the visual element of the screen.

 I'm using RDB to control the location of the objects, on the assumption
that only one is active at a time.  There are provisions to spawn a subprocess,
but only if the user specifically requests a concurrent process.  So far,
it works fairly well: multiple subprocesses don't kill the system.  Placing
all the tracking management in RDB reduces the overhead considerably.  (For
full implementation of a workstation of this type, contact Doug Brown
(SPRITE::BROWN)--he's done a lot of work with this sort of thing.)

 The big questions I'm running into aren't coding questions, but designing
the user interface.  What's best--keyboard or commands?  How should they
look?  What's the easiest way for the user to get around the information
set?
184.3DRZEUS::WALLMon Dec 23 1985 11:2324
Re: user interfaces

The issue of key combinations vs. commands is not the largest looming one.
From what I remember from my human-computer interaction classes and reading,
the idea is to make it consistent so that it will impress itself on the user's
memory and the user will pick it up faster.  Some examples are:

The Macintosh.  Weeding out the bells and whistles, the idea is you point,
click once for one result, twice for something more general.

EMACS.  While EMACS can be an unqualified mess at times, the idea of
Control-something to affect a character, Escape-something to affect some
larger entity represents what I'm talking about.  One sees the same idea in
the gold-key combinations in various keypads.

Commands, since they're words, are easier to associate at first with a function,
but keypads and the like are better once the user learns.  There's been a
million papers on this, and if what you're talking about is a project they
probably bear reading.

Boy, it's interesting to be able to enter this discussion after months of being
a voyeur.  Happy hacking.

Dave Wall