Conference bulova::decw_jan-89_to_nov-90

Re: .0

Answers: You presume correctly, Yes, and I'm also interested in hearing the
company line on this.  Will new applications be required/encouraged to
support both DECwindows and video terminals?

				-- Bob, with one foot in each world

    This isn't any 'company line' but last week DEC announced the availability
    of a product that will EVENTUALLY address just this problem. It is called
    DECforms and the current version (1.0) supports only character cell devices
    (VTs).

    DECforms Engineering is currently formulating plans for a DECwindows ver-
    sion. The DECforms program interface is such that the same application
    can be used to drive both a VT and a DECwindows interface (and eventually
    IBM 3270 and DECtalk and PCs and...) using the exact same application prog-
    ram regardless of the display device. DECforms isolates any device dependent
    information from the application program in a structure called a 'form'
    (what a surprise) that allows full use of the features of the target dev-
    ice (so it's definitely NOT a least-common-demoninator approach).

    Unfortunately, native DECwindows support is a year or so off... but if
    that's not a problem you can find out more about DECforms from its conf-
    erence:

               DSSDEV::DECFORMS

-mike

>    DECforms isolates any device dependent
>    information from the application program in a structure called a 'form'
>    (what a surprise) that allows full use of the features of the target dev-
>    ice (so it's definitely NOT a least-common-demoninator approach).

I keep seeing DECforms touted as a replacement for DECwindows and just 
can't bring myself to believe it.  Just because a DECforms application
can display through a server with buttons an pixmaps doesn't mean you 
can use the full functionality of DECwindows from DECforms.  The above 
statement kind of implys that you can throw out xlib, toolkit, and 
uil, never do another call to XtMainLoop and live happily ever after.

Somehow I just don't believe it!

    A *year*?  Gasp.
    
    Re: .3
    
    Will it remove the need for any other programming interface?  Hardly,
    but it will do essentially what GKS or PHIGS does for graphics for
    applications that are "forms" oriented, and a great deal of OLTP
    does.
    
    What isn't addressed yet is something akin to SMG.  That is, a general
    "windowing" character-cell-oriented interface that will run on
    DECwindows (native using all the cutsy stuff) and also on a terminal...
    for those *huge* numbers of applications that don't quite fit DECforms
    and don't quite fit GKS and *must* run on CCT's and WS and PC's.
    

RE: .3

No, DECforms is not intended to compete or displace the DECwindows toolkit. In
fact we plan to make use of the toolkit capabilities to provide our DECwindows
implementation.

The toolkit provide capabilities which allow the motivated user interface 
designer to have complete control over the display. DECforms on the other hand
provides the user interface designer a more structured environment where much
of the input processing is done by the DECforms model. We know that a large 
number of applications fit into DECforms model and thus DECforms is a tool which
reduces the effort to implement user interface designs. You give up some of the
freedom of expression, but gain in the time required to develop the interface.

This type of capability is especially important for those segements of the 
market where the user interface is only a small part of the entire application 
(for instance a large TP system, an office automation system). Why spend time
coding XtMumble when there's a tool which does the job? It's the same as saying:
"Why use Xlib when there's a widget that does what I want?".

As to being able to access every feature of DECwindows, or to replace DECwindows
entirely, we've never made this claim. We have simply stated that DECforms is 
a product whose goal is to provide a language (and editor tools) sufficiently
powerful to build a large class of user interfaces, many of which provide total
separation of the application function and display device management details.

Again, we invite you to join our conference at DSSDEV::FORMS.

RE: .4

Fred,

I'm not quite sure what you mean by �la SMG? A great deal of what you describe
fits DECforms exactly - windowing on character cell terminal, and also the 
ability to use DECW features on DECW terminals. 


James

    Yup. Except that there are two conferences:

        DSSDEV::FORMS - writelocked, but available for reading
        DSSDEV::DECFORMS - active conference

    We are especially keen to hear your ideas about the DECforms interface
    onto DECwindows. As James stated, the intent is not to compete, but to
    give added value to the whole environment.

-mike 


    

I want to state right up front that I am _NOT_ a hardware techy, _NOR_ an Xlib
cognosi, _NOR_ a DECWindows hacker (meant complimentarily). Nevertheless, IMHO...

DECWindows is an absolutely wonderful environment (just got it installed on my
VAXStation)! Tremendous learning curve, but incredible productivity potential!!

DECWindows is also incredibly expensive in terms of CPU/memory overhead (my VSII
could be compared to a car firing on only half of its cylinders since the 
installation of DECWindows). While I realize _NOTHING_ comes free, the overhead 
cost of DECWindows mandates a quick CPU and _AT LEAST_ 12 Mb of Additional RAM 
per user (by my observation, anyway).

The vast majority of current and potential commercial (especially TP) customers
use VT's, _NOT_ workstations (maybe the opposite is true for engineers, but...).
The cost of converting even 25% of the (let's say supervisors') VT's to 3100
class workstations is (currently) _SO_ prohibitive, I can't perceive any sales
person trying to pitch that to a commercial (TP) customer with a straight face.

The bottom line is, I can perceive a valid cost/benefit ratio for DECWindows in
the power user (ie - engineering) environment, where bitmap graphics and a CPU
per user is the norm, but I _CAN'T_ find anything resembling that positive
ratio for, let's say, a bank teller or insurance sales rep. Simply stated - A
VT320 clone can be had for <$500. A Mayfair class workstation _STARTS_ at about
$7,500 - _YOU_ justify the $7,000 difference!

Brian

RE: .5
>               -< DECforms is not competing with DECwindows!!!! >-

I agree, but this was the second time I'd seen someone answer a 
DECwindows question with DECforms and I think the user community is a 
little confused.  (The other one's in the Cobol notes file.)  BTW I 
did follow the DECforms notes file until I started supporting 
DECwindows and think it is a fantastic product for many, if not most, 
applications (so many good products and so little time!!).

.2 (DECforms) does not answer the question of having a CCT interface
when DECwindows is the required (or preferred) primary interface, so I 
think the .0 question is still open.

RE: -1
DECwindows terminals are available now from 3rd parties and will 
probably be up to snuff in about a year for $2,000.  It may still be 3 
or 4 times the cost of a CCT, but it puts the DW interface within 
reach of a LOT of users, to say nothing of managers who won't have 
that much trouble finding an extra $1,500.

RE: .-1, specificly:

``.2 (DECforms) does not answer the question of having a CCT interface
when DECwindows is the required (or preferred) primary interface, so I 
think the .0 question is still open.''

No, DECforms does not today provide you the ability to build both a CCT and
XUI based interface. It will in V2.0 however, give the user the ability to
do just that. 

For today, if one's application is such that it will fit into the DECforms
model, it is possible to use DECforms to build the CCT interface, and to use
direct calls to XUI/DECwindows to provide the DWT interface. Doing so may 
greatly reduce the complexity of supporting "multiple interfaces" in the short
term.

James

In Engineering Systems Group, MRO, our products EDCS and STARVIEW (DECview3D) 
need to support both DECwindows and character cell terminals. Many of our 
customers in the aerospace and automotive industries have large installed 
bases of terminals and it's important for us to help these customers migrate 
to DECwindows over time by providing software that will support both devices.

As a result, we have under development a user interface tool, called CIMI
(CIM Interface), that will be used by both EDCS V2.0 and DECview3D. It is 
currently being tested by both these products.

CIMI's goal is to duplicate the functions of a DECwindows user interface
on character cell terminals. It uses the VMS RTL Screen Management routines to 
mimic the menus, dialog boxes and windows of DECwindows interface.
CIMI itself exists as a layer between the application and the toolkit 
routines (either the DECwindows toolkit or the CIMI toolkit).  Applications 
that use CIMI will make calls to the CIMI interface. When the application is 
running in a DECwindows environment, the application call is passed directly 
through to the DECwindows toolkit. When the application is running on 
a character cell terminal, the application call is passed to the CIMI 
toolkit routine which is the equivalent to the DECwindows routine, but 
implements the call through SMG.

The idea here is that software developers can provide an application that will 
support both DECwindows and character cell terminals, in a single software 
kit.  There is no performance degradation to the DECwindows interface.  The 
user interface operates in similar ways on both types of devices -- 
only the method of input is different.

During the course of our development, we are finding that there are
limitations that the application developer needs to be aware of.
Implementation of a DECwindows style interface on terminals is limited to 
only what the terminal and its software can display. Applications need to 
take into account the limitations of character cell terminals when 
developing the user interface. For example:

. terminals cannot display bitmapped graphics - therefore if an application
  uses icons, the icon must be either replaced with text or represented
  by device-dependent graphics

. the coordinates and size of a character-cell terminal are different from
  pixel coordinates

. there is no mouse input on character cell terminals. All input comes
  from the keyboard, so moving between windows or between input areas
  can be cumbersome

. character cell terminals cannot use many of the window operations, such
  as resizing of a window or the cutting and pasting of text, that are
  common to the DECwindows environment

We plan to have CIMI baselevels available for testing in the August/September
timeframe. Anyone interested in being added to the distribution list
for these baselevels should send me mail on CURIE::SANDERSON. Once the
baselevels are available, I will contact you.

re: .10

While I applaud your efforts to support dumb character cell terminal, 
wouldn't it be sort of nice to support GRAPHIC terminals, like the 340 as 
well?  I even heard a rumor (unconfirmed) that you could actually attach a 
mouse to the 340...if so, why not support it?

Just asking.... ;-)  If I'm all wet, it wouldn't be the first time!

g.

    The application I'm developing uses graphics terminals (VT125, 240,330)
    and workstations.  I use GKS to achieve this "device independance".
    Of course, you still can't run it on a VT100.  Since the product
    is used in internal manufacturing, the user's equipment varies
    widely...
    
    Dave
    

Re: .11

>I even heard a rumor (unconfirmed) that you could actually attach a 
>mouse to the 340...if so, why not support it?

Was this written tongue-in-cheek?

The VT340 mouse can only be used in ReGIS mode.  Makes a nice paper weight...
It's difficult to get the mouse to do anything useful for text programs.  Also,
there are a lot more VT220s and VT320s out there than VT330s and VT340s.

				-- Bob

RE: .10

I would invite you to investigate the work that we've been doing with DECforms
and to consider using that as you character cell interface. While it's true that
there are several thing that you can't do with a character cell interface that
you can with a bitmapped interface, I feel you'll be impressed with the new 
capabilities that DECforms can offer. We have the capability to do screen 
artifacts like Caution boxes, Pulldowns, Dialog and Radio Boxes etc. Layering on
DECforms will save you a substantial amount of work!

I won't launch into a long discussion of what DECforms can do, so please come
join our conference on DSSDEV::FORMS and send mail to DSSDEV::WEBSTER. Bruce
will be glad to send you any information you need. 

James

P.S. We are also announced, with the V1.0 product shipping from the SDC.

   Correction to -.1: the conference is DSSDEV::DECFORMS.