perm filename CLWIND.MSG[COM,LSP]3 blob sn#777470 filedate 1984-11-26 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	Introduction
C00005 ENDMK
C⊗;
Introduction
Welcome to the Common Lisp Window Subgroup.
In order to mail to this group, send to the address:

		CL-Windows@su-ai.arpa

Capitalization is not necessary, and if you are directly on the ARPANET,
you can nickname SU-AI.ARPA as SAIL. An archive of messages is kept on
SAIL in the file:

			   CLWIND.MSG[COM,LSP]

You can read this file or FTP it away without logging in to SAIL.

To communicate with the moderator, send to the address:

		CL-Windows-request@su-ai.arpa

Here is a list of the people who are currently on the mailing list:

Person			Affiliation	Net Address

Kent Pitman		MIT		kmp@mc
Dick Gabriel		Stanford/Lucid	rpg@sail
Carl Hewitt		MIT		hewitt-windows@mc
Don Allen		BBN		allen@bbnf
Dan Oldman		Data General	not established
Larry Stabile		Apollo		not established
Tom Kaczuarek		ISI		kaczuarek@isi
Dave Matthews		HP		matthews.hplabs@csnet-relay (I hope)
Dan Stenger		TI		stenger.ti-csl@csnet-relay
Gary Brown		DEC		gbrown@dec-marlboro
Joe Ginder		PERQ		Joseph.Ginder@cmu-cs-spice
Thomas Gruber		Univ. of Mass.	gruber.UMass-CS@csnet-relay

The first order of business is for each of us to ask people we know who may
be interested in this subgroup if they would like to be added to this list.

Next, we ought to consider who might wish to be the chairman of this subgroup.
Before this happens, I think we ought to wait until the list is more nearly
complete. 

∂23-Sep-84  1610	RPG  	Introduction  
To:   cl-windows@SU-AI.ARPA 
Welcome to the Common Lisp Window Subgroup.
In order to mail to this group, send to the address:

		CL-Windows@su-ai.arpa

Capitalization is not necessary, and if you are directly on the ARPANET,
you can nickname SU-AI.ARPA as SAIL. An archive of messages is kept on
SAIL in the file:

			   CLWIND.MSG[COM,LSP]

You can read this file or FTP it away without logging in to SAIL.

To communicate with the moderator, send to the address:

		CL-Windows-request@su-ai.arpa

Here is a list of the people who are currently on the mailing list:

Person			Affiliation	Net Address

Kent Pitman		MIT		kmp@mc
Dick Gabriel		Stanford/Lucid	rpg@sail
Carl Hewitt		MIT		hewitt-windows@mc
Don Allen		BBN		allen@bbnf
Dan Oldman		Data General	not established
Larry Stabile		Apollo		not established
Tom Kaczuarek		ISI		kaczuarek@isi
Dave Matthews		HP		matthews.hplabs@csnet-relay (I hope)
Dan Stenger		TI		stenger.ti-csl@csnet-relay
Gary Brown		DEC		gbrown@dec-marlboro
Joe Ginder		PERQ		Joseph.Ginder@cmu-cs-spice
Thomas Gruber		Univ. of Mass.	gruber.UMass-CS@csnet-relay

The first order of business is for each of us to ask people we know who may
be interested in this subgroup if they would like to be added to this list.

Next, we ought to consider who might wish to be the chairman of this subgroup.
Before this happens, I think we ought to wait until the list is more nearly
complete. 

∂02-Oct-84  1311	RPG  	Chairman 
To:   cl-windows@SU-AI.ARPA 
Now that we've basically got most everyone who is interested on the mailing
list, let's pick a chairman. I suggest that people volunteer for chairman.

The duties are to keep the discussion going, to gather proposals and review
them, and to otherwise administer the needs of the mailing list. I will
retain the duties of maintaining the list itself and the archives, but
otherwise the chairman will be running the show. 

Any takers?
			-rpg-

∂13-Oct-84  1440	RPG  	Chairman 
To:   cl-windows@SU-AI.ARPA 

No one has been nominated as chairman of the Windows subgroup.  I
suggest Howard Cannon of Symbolics. If he is willing, and no one else
volunteers, he will become chairman. Please respond by October 24. At the
end of this month I want to see some ideas and proposals coming in on this
mailing list.

			-rpg-

∂25-Oct-84  0944	FILE-SERVER%WHITE.SWW.Symbolics@SCRC-RIVERSIDE.ARPA 	Chairman    
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 25 Oct 84  09:43:40 PDT
Received: from SWW-WHITE by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 94510; Tue 23-Oct-84 23:01:25-EDT
Date: Tue, 23 Oct 84 20:06 PDT
From: hic%SWW-WHITE@SCRC-RIVERSIDE.ARPA
Sender: FILE-SERVER%SWW-WHITE@SCRC-RIVERSIDE.ARPA
Subject: Chairman 
To: RPG@SU-AI.ARPA, cl-windows@SU-AI.ARPA
In-reply-to: The message of 13 Oct 84 14:40-PDT from Dick Gabriel <RPG at SU-AI>

    Received: from SCRC-STONY-BROOK by SWW-WHITE via CHAOS with CHAOS-MAIL id 47648; Sat 13-Oct-84 15:37:52-PDT
    Received: from MIT-MC by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 107864; Sat 13-Oct-84 18:32:38-EDT
    Date: 13 Oct 84  1440 PDT
    From: Dick Gabriel <RPG@SU-AI.ARPA>
    Subject: Chairman 
    To:   cl-windows@SU-AI.ARPA 


    No one has been nominated as chairman of the Windows subgroup.  I
    suggest Howard Cannon of Symbolics. If he is willing, and no one else
    volunteers, he will become chairman. Please respond by October 24. At the
    end of this month I want to see some ideas and proposals coming in on this
    mailing list.

			    -rpg-

Ah, I see I received this message.  I was worried that this mail wasn't
getting through, or was stuck at MC, or...

In any case, I respectfully decline the offer, not because I don't want
to do it but because of extensive traveling I don't feel I could be
reliable enough.  I do hope to participate actively, though.

I suggest that DDYER would do a fine job as chairman.

--Howard

∂27-Oct-84  2148	RPG  	Hello folks   
To:   cl-windows@SU-AI.ARPA 

We now have a chairman of the windows subgroup:  Dave Dyer of Symbolics. I
think he will make an excellent chairman.  For your information I am
including the current members of the mailing list.

I will now let Dave Dyer take over responsibility for the discussion.

David Matthews		HP		"hpfclp!windows%hplabs"@csnet-relay,
Jerry Boetje		DEC		Boetje@dec-hudson
John Foderaro		Berkeley	jkf@ucbmike.arpa
Steve Muchnick		SUN		"ucbvax!sun!muchnick"@berkeley
Howard Cannon		Symbolics 	"hic%scrc"@mc
Dave Dyer		Symbolics	ddyer@isib
Skef Wholey		CMU		Wholey@cmuc
Richard Zippel		MIT		rz@mc
Ron MacLachlan		CMU		RAM@cmu-cs-c
John Peterson		Univ of Utah	jw-peterson@utah-20
Kent Pitman		MIT		kmp@mc
Dick Gabriel		Stanford/Lucid	rpg@sail
Carl Hewitt		MIT		hewitt-windows@mc
Don Allen		BBN		allen@bbnf
Dan Oldman		Data General	not established
Larry Stabile		Apollo		not established
Tom Kaczmarek		ISI		kaczmarek@isi
Dan Stenger		TI		stenger.ti-csl@csnet-relay
Gary Brown		DEC		brown@dec-hudson
Joe Ginder		PERQ		Joseph.Ginder@cmu-cs-spice
Thomas Gruber		Univ. of Mass.	gruber.UMass-CS@csnet-relay
Ron Fischer		Rutgers		fischer@rutgers
Dario Giuse		CMU		dzg@cmu-cs-spice
Neal Feinberg		Symbolics	feinberg@scrc-stony-brook

∂28-Oct-84  1054	DDYER@USC-ISIB.ARPA 	Initial questions  
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 28 Oct 84  10:53:57 PST
Date: 28 Oct 1984 10:52:38 PST
Subject: Initial questions
From: Dave Dyer       <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA


Ok, since I have no idea what I'm supposed to do, I'll
just do what comes naturally.   What is the scope of
this discussion?  These questions come to mind:


What kinds of window hardware are we talking about?  Plain
glass ttys?  Bitmapped?  Vector?  Color?

What implementation technology?  Particularly, will we use
whatever the CL standard for objects becomes, or structures.

Fonts?  Text formatting?   What is the boundary between 
this mailing list and what "graphics" will discuss.

What about pointing devices?
-------

∂29-Oct-84  0917	DDYER@USC-ISIB.ARPA 	Initial Answer
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 29 Oct 84  09:17:19 PST
Date: 29 Oct 1984 09:12:53 PST
Subject: Initial Answer
From: Dave Dyer       <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA

[ Editors Note:  Since this reply came to me rather than the mailing list,
  I am reminded of the perpetual question;  "To Digest or not to Digest"
  For now, I will package any replies that come directly to me, and send
  them to the mailing list from time to time.   Messages sent to 
  cl-windows@su-ai will continue to be redistributed immediately.
						DDyer@isib]

Return-Path: <KACZMAREK@USC-ISIF.ARPA>
Date: 29 Oct 1984 07:47:00 PST
Subject: Re: Initial questions
From: Tom Kaczmarek <KACZMAREK@USC-ISIF.ARPA>

Regarding interaction with the graphics group, I think we ought to try to 
build on top of what they supply.  I suspect that there is enough cross-
membership to insure that we have sufficient influence.  (I haven't compared
the mailing lists so I could be wrong about that.)

[ddyer: I tend to look at it the other way; Graphics is an additional
 behavior of windows, and graphics capabilities will be built out of
 whatever we supply.]

As far as display hardware goes there seems to be two interesting classes--
"graphics" and glass ttys.  Color is an orthogonal issue, isn't it?
Number of bit planes for black and white graphics falls in this same
category.  Both graphic devices and ttys come in black and white (with
intensity levels) or color.  Graceful degradation seems to be the
appropriate way to handle these issues.  I believe the graphics people
having been looking at this issue for some time and have solutions for this
problem.  

I would guess that if the graphics group does its job well, vector versus
bitmapped graphics should not be an issue.  The resolution of the graphics
may be an issue however.  Low resolution graphics devices seem a lot like
glass ttys as far as windows go.  Storage vector graphics hardware (ala
old Tektronix stuff) does not lend itself to the kind of interaction one
expects from a window system so I think we can eliminate it.  I believe the
graphics group also should make pointing devices less of a problem since
graphics standards have abstracted actions like "picking."  I believe that
complex mouse buttoning will still be something of a problem.

Structures versus objects seems to be a difficult decision.  Perhaps having
to wait for a object standard will be the best argument for structures.
Conceptually, objects are nice for the kind of interactions that occur in
the window world.  Is efficiency an issue here?  Object-oriented
implementations seems to rely on interpretation rather than compilation.
Is that because nobody has done it differently or is it too hard?  Or
impossible?  Or am I wrong about that?

[ddyer: flavors are compiled]
Tom
-------
-------

∂29-Oct-84  1045	boetje@DEC-HUDSON 	some initial answers(?)   
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 29 Oct 84  10:43:09 PST
Date: Mon, 29 Oct 84 13:39:39 EST
From: boetje@DEC-HUDSON
Subject: some initial answers(?)
To: cl-windows@su-ai.arpa

Ok, it's Monday morning and I'm ready to take on windows. This note is in 
direct reply to Dave Dyer's set of questions over the weekend. 

Let's take the terminology question first. I have a strong feeling that we 
need to get this handled before much else can happen. One of the major 
difficulties in this area is that there seem to be two different views of what 
the term "window" refers to. Most everyone working on bitmapped screens these 
days calls the funny rectangular areas (with borders and labels, in which you 
can put text or draw lines) windows. The graphics community uses "window" in a 
very different way. A window is really a way to specify a set of coordinate 
transformations and a set of bounding coordinates for clipping purposes. You 
can't ever see a graphics window. It takes a viewport to make that happen. 
Viewports are potentially viewable objects. But of course in that graphics 
world, there isn't a firm concept of borders and labels.

I will put forth the following radical suggestion: the graphics folks were 
here first, so their terminology should take precedence. Windows and viewports 
are strictly defined in the world of real graphics. A window is a set of 
limiting coordinates (x-y min and max values) in some arbitrary system
(usually the coordinate system of the data values to be plotted). This defines 
the aspect ratio of the eventual display of data. A viewport is another set of 
limiting coordinates which are used to map the data plotted in coordinates of 
the window to a displayable rectangle (this provides for clipping, 
magnification, and transformation to the physical device).So we won't do 
windows (sorry about the marketing slogan). We need to call those funny 
rectangles on the screen something else.

Before I unveil my terms, let me introduce a concept into this arena. In both 
the graphics world and whatever-we-call-the-current-thing world, there is the 
idea of a displayable object. In the graphics world, viewports can be 
displayable objects (when they map things from NDC space for example). They 
can also be previously created "pictures" which can be used to make composite 
images (for example, the symbol for a NAND gate in a CAD system). The common 
term for this object is "segment". Segments can be replicated and scaled ad 
nauseum to make a larger displayable object. The graphics world thus has a 
model of composition by using displayable objects as well as basic line 
drawing primitives.

In the bitmapped world, "windows"  are considered displayable objects. In the
case of Symbolics, they also  provide the idea of decomposition of their window
into "panes" (which can be  treated as individual windows for many purposes).
Another way of looking at  their system is that they treat their "window" as a
displayable object which can be composed of other windows. Their composition 
process also involves a particular contraint system on the interaction between 
the parts of a composed displayable object (resize one and the others adjust).

With all that said, I now introduce my own terms (liberally borrowed from 
unnamed sources):

1. Virtual Display. This is what most folks think of as a "window" or perhaps
a bitmap (depending on whether it's visible or not). You may see it (touch it
and taste it if it's late enough at night) on the screen. It's a  rectangular
area which may be made to appear on a physical display (hence the term virtual
display) which  can have a border, a label, etc. Primitive operations can put
information into  the display (like writing characters or drawing lines). If
they are not currently visible on the physical display, their current state is
kept and  modified by primitive operations. 

They can also be  composed of other virtual displays with appropriate
constraints at the whim of the implemectation. It may or may not be on the
physical display and it may or  may not be hidden obscured by other visible
displays). It can function as an I/O device for CL streams. And if you're into
the graphics side of the world, viewports map directly into the non-border
portion of virtual displays.  

2. Windows and viewports retain (and will only be used for describing) their 
traditional meanings in the world of graphics (which among other things means 
that windows and viewports operate in coordinate systems other than that of 
the physical display device).

3. Displayable object. Well, I gave the sense of it above. If we want to 
strictly define it for CL, then we'll need to do some work on it. I'm inclined 
to leave it alone for now and just use it by way of introducing concepts of 
composition. We'd need to be very closely tied to the graphics folks if we 
want to define it in the language.

Ok, enough on terms. Hardware... hmm... Curiously, the most limiting hardware 
is the vector drawing equipment, because it's hard to change once you've put 
it on the screen. My thought is that we should at least define operations that 
can be done on a cell-oriented screen. We can define optional capabilities for 
displays, but that gets us into the serious business of specifying how the 
user program determines the capabilities that can be used on the runtime 
device and what the error mechanism is for operations that can't be supported 
on the current device. The GKS graphics folks have done this and the inquiry 
functions outnumber the primitive operations.

On the software implementation, we should go for the least disruptive and 
commonly implemented features (GCLISP has some nice display stuff on a small 
machine). I think this means structures, not objects. We might want to define 
an optional object interface to the displays, but I think we need the simple 
level as well. Also, I don't want to wait around for the religious wars over 
objects. We'll have enough of our own...

Fonts, et al. Ok, we need some optional ways to specify font information and 
it's not clear that font bits are the best way to go. VAX LISP would probably 
have a difficult time handling font information in strings (efficient strings 
for us are one byte per character). Font information should be an ignoreable 
parameter (VT200's don't do well when commanded to go into Times Roman). 
Having a function that computes the actual screen size of a string in a 
specified font is a must.

Text formatting. We need text primitives to write, erase and insert 
characters. But I'm not anxious to get into the business of putting Scribe 
into CL. But there should be enough functionality for the cottage industries 
to write a formatting system on top of the CL primitives.

Boundary between this group and graphics. Ok, I've got a foot in both, so I'll 
jump in. We should stick to the ideas of virtual displays and composition of 
virtual displays. They should always operate in the coordinate system of the 
device. The graphics world should get windows, viewports and segments and 
operate in non-device coordinates. Our major interface then becomes a mapping 
of viewport to virtual display with the graphics side worrying about the 
scaling and clipping into the device (virtual display) coordinates.

Last topic for now... pointing devices. hmmm. They're needed for two purposes,
at least. One is to do operations on entire virtual displays (like popping
them to the surface). They other is to indicate a point or segment within a
virtual display. These operations can be handled with mouses and tablets and
can be simulated with cursor keys. We have to be careful not to get into the
business of defining a user interface to CL (pointing at a label brings a
display to the surface). But it would be nice to have some simple functions to
let users roll their own. 

Indicating a point or segment is a bit more interesting and gets us involved 
with the graphics group. Points within a virtual display need to be returned 
in some coordinate system. Most bitmap systems give back a point in raster 
coordinates. That's probably limiting. The graphics world likes them returned 
in the original coordinates used to draw the picture. And picking graphics 
segments has a close counterpart in defining/selecting a sensitive region.
Topic for next time.

Oh yes, color. Pick and stick to one of the international standards. There's 
RGB (red, green, blue) and HLS (hue, lightness and saturation). Any of you 
VideoText folks probably have yet another way. I have no real preference (just 
a minor leaning to HLS) but I haven't figured out if I should grind an ax on 
this or not. Issue deferred...

	Jerry

∂30-Oct-84  0711	dzg@cmu-cs-spice.arpa 	Terminology, etc.
Received: from CMU-CS-SPICE.ARPA by SU-AI.ARPA with TCP; 30 Oct 84  07:10:20 PST
Date: Tuesday 30 October 1984 09:33:00am-EST
From: dzg@CMU-CS-SPICE.ARPA
To: cl-windows@su-ai.arpa
Subject: Terminology, etc.
Message-ID: <0.0.dzg>

I mostly agree with Jerry Boetje. Let's use "window" for a set of bounding
coordinates; the confusion in the bitmap world is hopeless anyway. As an
example, on the Perq a 'viewport' is a rectangular portion of a display, and
a 'window' is essentially a viewport embellished with borders and a
'title'; on the Symbolics, a 'window' is essentially a viewport that may or
may not have borders and a 'label' (title).

I have a little problem with the term "segment", just because it is so
overloaded. I would try and suggest "symbol", a' la Newman & Sproull, just
because it's nice to talk about a symbol and a symbol instance. I realize,
though, that the word "symbol" is also overloaded...
One related question is transformations: can you only specify a
transformation (rotation, scale, offset) for symbols|segments, or can you
transform any graphical object in place?  Do you want to be able to say
"This is an arc of a circle, center and radius such and such, and by the
way it is scaled up 3.2 and rotated pi radians"?  Or do you always have to
wrap the arc in a symbol|segment to achieve the same effect? 

I also agree that we should use the universally available Structures for
the software implementation, given that no universally accepted (or
implemented!) notion of object seems to be around the corner. The BIG
problem, here, is that if you are not very careful your structures turn out
to be a "display list" that the system maintains, and so you have to
duplicate them all to put the interesting stuff you want to deal with. One
of the ideas I am trying to work on is to SHARE your data structures with
the system, so that you can have all the nice slots you want in there that
are not graphical at all, while the system can store all its internal cute
optimization things in it. This is unfortunately difficult to do with
structures a' la DefStruct, since the slots are defined once and for all.
An object system would be much nicer, since the system can define all its
nasty things and you never need to know about them.

Fonts: the "best approximation" paradigm should apply. My approach would be
to have a very generic font definition (family name, face, size, rotation)
which would be mapped into whatever the system provides. Font names are
totally hopeless (What's a CPT10? Is it 10 points or 10 pixels? Or is it
the 10th font in the file CPT? And what's a CPT anyway?), so I think one
would end up having a device-dependent mapping between an "abstract font"
and whatever the system provides. The mapping would be very dull on the
VT200, for instance, but one should use an abstract specification
nonetheless.

I very strongly oppose any notion of text formatting. Only the very minimal
level of support, including obviously the ability to get device-dependent
font information (IN WORLD COORDINATES, not in device coordinates!), should
be present. More complex text formatting is A) highly dependent on personal
taste, and B) extremely difficult to do right for sophisticated
applications. I certainly don't want a window system at this level to have
to deal with kerning and italic corrections.

  - Dario -

∂31-Oct-84  0723	STENGER%ti-csl.csnet@csnet-relay.arpa 	re: inital answers   
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 31 Oct 84  07:23:51 PST
Received: from ti-csl by csnet-relay.csnet id ad00735; 31 Oct 84 10:18 EST
Date: 31 Oct 1984 0625-CST
From: Dan Stenger <STENGER%ti-csl.csnet@csnet-relay.arpa>
Subject: re: inital answers
To: cl-windows%su-ai.arpa@csnet-relay.arpa
Received: from csl60 by ti-csl; Wed, 31 Oct 84 09:13 CST

On terminology:
I agree with Jerry Boetje's proposal on the terminology that we should use.
We should settle on something so that we all understand each other.  The
main problem I see with this is that the terms "windows" and "panes" are
well established in the Lisp community and we may just cause confusion.

On bounds of this group:
I am also in the graphics group.  My view is that we should limit the
efforts of the windows group to virtual displays and other things that
need to work in device coordinates.  The graphics group should handle
what is shown in the virtual displays.

On the software implementation:
I agree that structures are the way to go.  Some implementations may not
want the object oriented programming system but may want windows.  Also
the wait may just put us too far behind.

On display hardware:
It would be nice if what we come up with is compatible with vector refresh
and storage tube hardware but I do not think that we should concern ourselves
with it.  The types of hardware which we do need to address are black/white
and color bitmaped terminals, and text only terminals.

In general I think we should try to design something that is concise, simple,
but very general.  It should be implementable on small machines but be easily
extended (not restrictive) for larger machines.

		Dan Stenger
-------

∂02-Nov-84  2330	DDYER@USC-ISIB.ARPA 	Real devices (mainly)   
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 2 Nov 84  23:30:41 PST
Date:  2 Nov 1984 23:26:10 PST
Subject: Real devices (mainly)
From: Dave Dyer       <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA


There seems to be consensus that vector displays are outside
our domain.  If there are no devotees of vector displays out
out there, I'll consider it official.

I liked "virtual display", but one term isn't a complete glossary.


  Several messages have cast a word in favor of supporting ordinary
terminals; but I wonder just how much one can do, especially if
"virtual display" is taken to imply "multiple virtual displays".
In practice, won't terminals be restricted to one or two virtual
displays, all the same width as the screen?   I've done quite
a bit of display hacking on ordinary terminals, and found anything
fancier to be aesthtically awful, even if technically possible.

  There simply isn't enough real estate to distinguish more than
a few windows, aren't display capabilities to provide margins
and borders, and the devices themselves don't operate fast or
reliably enough to allow manipulation of arbitrary blocks of
characters in a way that is acceptable to users.   Shouldn't we
take this ugly bit of reality into account? 

  I'm not necessarily proposing we punt terminals entirely, but
we should at least consider defining a limited set of primitives 
for terminals sufficient for input editing and (maybe) emacs style
editing.




  I also have doubts about several mentions of "device coordinates"
as the appropriate substrate for virtual displays.   One at least
needs to be able to speak of either "characters" or "pixels", to
accommodate ordinary terminals and bitmaps, but once pixels are
introduced, a whole nest of other problems surface; such as
aspect ratio, variable width and height of fonts, and the variable
size of pixels on different displays.  

  For a particular display, one could of course tweak things into
the right device coordinates to give the desired effect, but we
are speaking "portable" here, so need to at least address the question
of transmitting the author's intent to foreign systems.   

  Just to finish on a concrete point, consider Symbolic's color
displays, where the "same size" characters (in device coordinates)
border on unreadable compared to the same text on the B&W screen.   
Also, consider that a single pixel height horizontal line on a
noninterlaced screen is fine, but on an interlaced screen it is
probably unacceptable due to excess flicker.

  No program that operates in "device" coordinates can ignore facts
of life such as these.  We need to strike a balance between providing 
access to the raw facts, and hoping programs cope with all the possible
implications, and attempting to abstract intent into our specs and letting
the implementation cope with the ramifications.



-------

∂03-Nov-84  0747	FAHLMAN@CMU-CS-C.ARPA 	Goals  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 3 Nov 84  07:47:49 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 3 Nov 84 10:47:55-EST
Date: Sat, 3 Nov 1984  10:47 EST
Message-ID: <FAHLMAN.12060631562.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   cl-windows@SU-AI.ARPA
Subject: Goals


In my opinion, the window group is really in the business of developing
one or more optional semi-standards.  What I mean by that is that I
don't think that the Common Lisp specification should require any
particular sort of display or window system in order for something to be
called Common Lisp.  Display technology is moving pretty fast, and we
wouldn't want to rule out a Common Lisp in a wristwatch or a Common Lisp
running on a brute-force machine with no display of its own.
Furthermore, each machine running Common Lisp will have a few
specialized high-performance tricks available that users will want to
access for the most demanding applications: one machine might have a
hardware font and vector generator, another might have an incredibly
smart rasterop, and so on.  

But what we can and should do is to develop one or more clean interfaces
for doing some collection of popular things on certain popular families
of display technologies.  Implementors will be encouraged to provide
these standard interfaces on their machines wherever they make sense,
and people developing display-oriented code will then have the option of
writing it using the portable interface, for easy portability across a
class of machines, or of writing it to make the best possible use of a
given machine using whatever tense non-standard mechanisms may be
available.

It seems to me that three families of display device are going to be
important in the near future: 24x80 character terminals with varying
degrees of crude graphics support, high-resolution (at least 600 x
800) monochrome bit-mapped displays with some sort of pointing device,
and high-res bit-mapped displays with color.  Rather than ruin the
interface we develop for bit-mapped displays by trying too hard to make
it all work on ASCII terminals, I propose that we define three separate
interfaces:

Level 1: Can be implemented on the majority of ASCII termianls.
Level 2: Assumes bit-mapped graphics, reasonable resolution, and a
         pointer.
Level 3: Same as above, but with color.

Software developers can target their software to raw common Lisp or to
any of these levels, depending on the capability they need and the
market they wish to address, or they can go native on a single
machine/system.  Maybe levels 2 and 3 can be collapsed into one.
This is set up as a sort of hierarchy, since I am assuming that any
machine providing level 2 support will also provide level 1 support and
so on.  But the situation is really not hierarchical -- one might
imagine vector displays as wanting a different kind of interface
altogether.

The most important need right now is to come up with something for level
2, since the vast majority of Common Lisp implementations (not weighted
by number of users) is on machines of this class.

-- Scott

∂04-Nov-84  1816	JW-PETERSON@UTAH-20.ARPA 	Some responses...  
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 4 Nov 84  18:16:37 PST
Date: Sun 4 Nov 84 19:16:54-MST
From: John W. Peterson <JW-Peterson@UTAH-20.ARPA>
Subject: Some responses...
To: cl-windows@SU-AI.ARPA


VT100's.  The 24x80 terminal may not be dead, but is quickly dying.  A
reasonably intelligent bitmapped terminal with a mouse runs around $2K, and
will shortly drop to the VT100 [& clones] price range - this seems like a
good "lowest common denominator" level.

Fonts.  The discussion of fonts and formatting brings up an interesting
analogy: When the world migrated from TTY's to CRT's, many programs broke
(or just "looked ugly") because they couldn't deal with lower case input or
output.  The same sort of thing appears to be happening again, only this
time things are breaking (or just not looking right) because they can't deal
with multiple fonts - particularly ones with proportional spacing.  Having
at least some formatting facilities inherent in the window system (e.g., tab
stops that work correctly with proportional spaced fonts) would make the
programmer's life noticeably easier.

Units of measure.  Is anything wrong with measuring things in Pixels?  It
makes life much, much simpler (both conceptually and pragmatically) to
define screen coordinates in pixel units.  There is nothing very "display
specific" about pixel units of measure, particularly when you consider
"Virtual Displays" are usually of various sizes on the same screen.  As long
as we use digital computers, screens will be measured in discrete units -
both graphics and window packages might as well behave the same way.
(An interesting discussion of this is presented in "A Language for Bitmap
Manipulation" by Guibas & Stolfi in the July '82 Transactions on Graphics.)
-------

∂19-Nov-84  0019	DDYER@USC-ISIB.ARPA 	Proposals and questions 
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 19 Nov 84  00:19:31 PST
Date: 19 Nov 1984 00:18:26 PST
Subject: Proposals and questions
From: Dave Dyer       <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA

I like Scott Fahlman's notion of defining two sets
of protocols, one for simple terminals and the other
for rasters.  Presumably the terminal protocol would
use characters and lines as its units, while the
raster protocol would use either characters or pixels.

Are there any existing standards we might use as a
starting point?   I'm hoping for something more abstract
than the lisp machine window system manual!  The first 
proposal circulated is likely to become the de facto standard.


In accordance with the above, I suggest the following
framework:

Each virtual display divides the world into three parts,
INSIDE, BORDERS, and OUTSIDE.  

INSIDE a virtual display, two protocol sets are defined,
a "character oriented set" and a "raster oriented set".
The character oriented set deals with size, positioning,
font and other characteristics of characters.  The
raster oriented protocol also addresses characters,
but also any other graphics and display primitives.
It is permitted for an implementation to implement only
the character oriented protocol.


OUTSIDE a virtual display, protocols deal with its
size, position, visibility and so on with respect to
its superior.


I'm not sure how to encapsulate the notion of BORDERS
succinctly.  The best I can think of at the moment
is that borders are a specialization of the more general
notion of "clipping region"; that a window is defined
by a clipped region within its superior, and may
in turn define an inferior clipping region.



		 ANOTHER NEW QUESTION

I'm personally a little worried by the consensus to implement
virtual displays using structures.  By way of bringing my
concerns to the surface, I'll pose a question:

 How much user extensibility to window system behavior will be
expected/permitted, and how will the data structure and procedural
hooks for that extensibility be supported?


 I think it is important that extensibility be a goal, and that
"extended" windows (oops! virtual displays!) be as well integrated
and as efficiently implemented as the system's supplied windows.
I know how to do this in an object oriented window system.  Tell me
how you'll do it in a structure based system.


-------

∂19-Nov-84  2035	WHOLEY@CMU-CS-C.ARPA 	Proposals and questions
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 19 Nov 84  20:34:25 PST
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Mon 19 Nov 84 23:33:14-EST
Date: Mon, 19 Nov 1984  23:33 EST
Message-ID: <WHOLEY.12064965182.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To:   Cl-Windows@SU-AI.ARPA
CC:   Dave Dyer <DDYER@USC-ISIB.ARPA>
Subject: Proposals and questions
In-reply-to: Msg of 19 Nov 1984  03:18-EST from Dave Dyer <DDYER at USC-ISIB.ARPA>

Here are some of my thoughts on "virtual displays," both their specification
and their implementation (via structures).

There are (currently) about three coarse levels in virtual display fanciness
that a virtual display system should try to support:
	Glass TTY with at least an addressable cursor (e.g. ADM-3A)
	"Smart" CRT terminal (e.g. Concept-100, VT-200)
	Bitmapped displays

I believe that any virtual display should support all operations (we have yet
to decide on the operations, but my point is that something like DELETE-CHAR
can be performed on any of the above, albeit with different performance).  Non-
bitmapped terminals could be treated as having 24 by 80 (or whatever) pixels,
and a 1 by 1 font.

The redisplay module of a text editor will want to use different screen update
algorithms depending on the sort of virtual display it is writing to.  Thus, a
virtual display should be able to provide information about the relative
efficiency of its operations.  At the very least, a programmer should be able
to find out in which of the three categories listed above a virtual display
belongs.  The editor's redisplay algorithm can then be tuned to the particular
output device.  The casual programmer could of course opt to ignore this extra
information.  The virtual display machinery could do all kinds of redisplay
optimization itself, but I believe that certain decisions are best made in the
client program.

Thus, the different "protocols" that Scott suggests would be kept at a level
below the virtual display operations, but programmers that wanted to could
easily figure out useful things about the implementation of a particular
virtual display.

We at CMU have had a good deal of success implementing streams with structures,
which leads me to believe that they'll be sufficient for implementing virtual
displays as well.  Our stream structures store both functions ("methods") and
data ("instance variables").  Common Lisp DEFSTRUCT provides inheritance
through the :INCLUDE option, which makes streams (somewhat) easily extensible.
I realize that this system is less flexible than one built on flavors (or any
other real object-oriented programming system), but it is highly portable, and
gives you 90% of the extensibility you'd ever want.

Thus, we might define a virtual display like this:

	(defstruct vd
	  "The root Virtual Display structure."
	  ;; Methods:
	  display-char				; Method for Display-char
	  display-string			; Method for Display-string
	  delete-char				; Method for Delete-Char
	  ...
	  ;; Instance variables:
	  width					; Width in pixels
	  height				; Height in pixels
	  cursor-row				; Row that the cursor's on
	  cursor-column				; Column the cursor's on
	  ...)

	(defun display-char (vd char)
	  "Displays the Char at the current cursor position of the VD,
	   moving the cursor appropriately."
	  (funcall (vd-display-char vd) char))

	...

Then we could define a particular kind of virtual display like this:

	(defstruct (c100-vd
		    (:include vd
			      (display-char c100-vd-display-char)
			      (display-string c100-vd-display-string)
			      ...))
	  "The VD for Concept-100 terminals."
	  ;; Additional instance variables:
	  stream)

	(defun c100-vd-display-char (vd char)
	  (write-char (c100-vd-stream vd) char)
	  (cond ((char= char #\newline)
		 (setf (vd-cursor-column vd) 0)
		 (incf (vd-cursor-row vd)))
		(t
		 (incf (vd-cursor-column vd)))))

	...

That's just an example of the sort of thing one can do, and none of the
particular operations should be taken as suggestions for how a virtual display
should work.

Yes, it's more verbose than flavors, but it is portable and perhaps more
efficient than a flavor-based system would be.  Such a system CAN be extended
by the user.  Do you still think we'd be too constrained by implementing a
virtual display system with structures?

--Skef

∂19-Nov-84  2220	FAHLMAN@CMU-CS-C.ARPA 	Proposals and questions    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 19 Nov 84  22:17:38 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 20 Nov 84 01:16:25-EST
Date: Tue, 20 Nov 1984  01:16 EST
Message-ID: <FAHLMAN.12064983964.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Cl-Windows@SU-AI.ARPA
Subject: Proposals and questions
In-reply-to: Msg of 19 Nov 1984  23:33-EST from Skef Wholey <Wholey>


I agree with much of what Skef Wholey says -- especially the part about
being able to find out which class of display device you have -- but I
don't think I agree that "any virtual display should support all
operations".  The problem is that there are some things you want to do
on a bitmap that just have no counterpart on a 24x80 ASCII terminal
(smart or not).  If we throw all of these things out, we get an interface
for bit-mapped displays that is less powerful than it should be, which
means that more users will write their code using non-standard calls to
get at the display's real power.

Probably the right move is to make the operations for the feeble
displays a subset of those available on the more powerful ones.  In some
cases, we might want the operations for more powerful displays to
recognize additional keywords (such as :COLOR).  We should try to keep
the number of distinct levels fairly small, however.

On the issue of whether to use objects, I think that we cannot define an
object-orineted interface until the Common Lisp community settles on
some particular object-oriented system as being required on all
implementations (though other object systems might co-exist with this).
I don't expect to see this any time soon -- if a standard is to emerge
at all, it will only be AFTER people have had a chance to play with
portable Flavors and Loops and assorted other things and decide what
they like.  I think that we can define a reasonable set of
somewhat-extensible interfaces in a portable non-flavorish way; if we
have to sacrifice some extensibility, that's better than having no
common window interface at all.

-- Scott

∂20-Nov-84  0736	boetje@DEC-HUDSON 	documenting implementations    
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 20 Nov 84  07:35:44 PST
Date: Tue, 20 Nov 84 10:36:01 EST
From: boetje@DEC-HUDSON
Subject: documenting implementations
To: cl-windows@su-ai.arpa

I think the discussion of structures vs object implementation is getting a
little off track. The issues (it seems to me) revolve around the form of the
creation, accessing and setting functions for virtual displays and the method
by which the user can extend the functionality of the virtual display system
Let me address some high level considerations of each issue.

When I say that I prefer a structure implementation for the CL standard, I'm 
not saying that I intend that the DEFSTRUCT for various things be defined in 
the standard. My intention is that we document and standardize creation, 
accessing and setting functions that look like

	(setq display-1 (make-virtual-display ...))
	(virtual-display-label display-1)
	(setf (virtual-display-label display-1) ...)

as opposed to instancing of objects and sending messages to the instances. I 
think that under no circumstances should we document a particular DEFSTRUCT 
implementation and require all Common LISPs to have this. I think that the 
only reason to do this (and it's part of the example Skef gives) is to allow 
users to support output devices not explicitly supported by the vendor. This 
will get us rapidly down a rat hole of terminal support issues. Support of 
"non-vendor" terminals should be an issue for the vendor to address in 
whatever way is most efficient on his system. On the other hand, functions 
such as SET-CURSOR-POSITION should exist in all the CL implementations and do 
the right thing on all supported terminals. If the vendor provides an 
implementation dependent way to define support for other terminals, then the 
positioning function will do the right thing on these other terminals as well. 

Extending the capabilities of operations on virtual displays is a real issue. 
On the other hand, it's not clear that we have to address this right now. I 
propose that we investigate defining a fairly "complete" range of 
functionality which assumes the availability of a nice (color, bitmapped) 
display and then look at subsetting this functionality to cell-oriented 
terminals. A part of this may be defining a number of inquiry functions which 
let the program tailor itself to the capabilities of the run-time device. This 
means that we're likely to end up in the same place as the GKS standard which 
has more inquiry functions than all the other kinds of function combined. 

We can probably have some high level inquiry functions that let the user know
the general category of device (bitmapped, color, vector, cell, etc). Each
category would have a certain level of functionality that's required (by the
standard) for that device and a certain set that's optional and up to the
implementation (eg, narrow virtual displays on a VT100).

∂20-Nov-84  0850	WHOLEY@CMU-CS-C.ARPA 	Virtual Displays  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Nov 84  08:49:57 PST
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Tue 20 Nov 84 11:48:43-EST
Date: Tue, 20 Nov 1984  11:48 EST
Message-ID: <WHOLEY.12065099060.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To:   CL-Windows@SU-AI.ARPA
Subject: Virtual Displays

    From: Scott E. Fahlman <Fahlman>

    I don't think I agree that "any virtual display should support all
    operations".  The problem is that there are some things you want to do
    on a bitmap that just have no counterpart on a 24x80 ASCII terminal
    (smart or not).  If we throw all of these things out, we get an interface
    for bit-mapped displays that is less powerful than it should be, which
    means that more users will write their code using non-standard calls to
    get at the display's real power.

I believe that the sorts of things you're talking about are in the domain of
CL-Graphics.  I could be wrong.  Could you give me an example of such
operations?  I have a feeling that either they should be hidden by something
very high level (e.g. HALFTONE-RECTANGLE could really halftone a portion of a
raster display, but put a portion of a Concept-100's screen into half-bright
mode), or that they can be implemented by mashing vanilla CRT's into 24x80
raster displays using 1x1 fonts (MOVE-RECTANGLE could do a BITBLT on a raster
display, but actually copy stuff around on other terminals (actually, for dumb
termiansl this would require the VD system to maintain a screen image, which
may or may not be a good idea (but Concept-LNZ's DO have such an operation))).

Perhaps we need to decide on operations before we determine if there needs to
be the distinction that Scott suggests there ought to be.  I think a virtual
display should try its best to perform an operation, but quietly ignore the
request if it can't hack it.  It could bum someone out if a nifty piece of
software didn't run on her computer just because she had a dumb terminal.  If
instead, the display just didn't look as nifty on an ADM-3A as it does on a
Lisp Machine, then the user will probably be forgiving.

    From: boetje at DEC-HUDSON

    I think the discussion of structures vs object implementation is getting a
    little off track.

I was attempting to show that the niceness of an object-oriented approach could
still be had within the Common Lisp language, and with structures.  Perhaps I
should have said "Object oriented programming is a style, and one can write
stylized Common Lisp," and left out all the code in my last message.

    My intention is that we document and standardize creation, accessing and
    setting functions that look like
    ...
    as opposed to instancing of objects and sending messages to the instances.

Sure.  Note that the Display-Char function (intended to be the user-level call)
in my example hid the object oriented implementation.  Streams are the done the
same way, for us.

    I think that under no circumstances should we document a particular
    DEFSTRUCT implementation and require all Common LISPs to have this. I think
    that the only reason to do this (and it's part of the example Skef gives)
    is to allow users to support output devices not explicitly supported by the
    vendor.

So we're just working on a spec here, and not a portable implementation.  Ok.
I think a portable implementation or two will come out of this, though.  The
people doing those implementations probably want to think hard about
extensibility for the sake of porting to new environments in addition to
supporting new devices.

    We can probably have some high level inquiry functions that let the user
    know the general category of device (bitmapped, color, vector, cell, etc).
    Each category would have a certain level of functionality that's required
    (by the standard) for that device and a certain set that's optional and up
    to the implementation (eg, narrow virtual displays on a VT100).

I have a feeling that trying to do things in explicit levels is going to let
capabilities of some terminals fall through the cracks.  I claim that the
problem Scott brought up in the first paragraph quoted above can work in
reverse -- some character-oriented CRT's can do operations like
raster-oritented displays, and others can do different ones.  Maybe this isn't
a problem, but we can't tell for sure until we get into specifics.  Anyone up
for that?

--Skef

∂21-Nov-84  0724	FAHLMAN@CMU-CS-C.ARPA 	Virtual Displays 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 21 Nov 84  07:23:14 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 21 Nov 84 10:22:01-EST
Date: Wed, 21 Nov 1984  10:21 EST
Message-ID: <FAHLMAN.12065345435.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Skef Wholey <Wholey@CMU-CS-C.ARPA>
Cc:   CL-Windows@SU-AI.ARPA
Subject: Virtual Displays
In-reply-to: Msg of 20 Nov 1984  11:48-EST from Skef Wholey <Wholey>


I'm not sure if my view of the dividing line between CL-WINDOWS and
CL-GRAPHICS matches other people's.  I had been assuming that such
things as the primitive calls to display characters in a window at
arbitrary places, draw lines, color in rectangles, and so on were the
provine of the window package, and that any graphics standard is more
concerned with higher-level software to help decide which lines to draw
where.  (If graphic means anything that is written into a virtual
display at all, then we have to consider graphics and windows together
because at that level they are inseparable.)

If my view of the division is correct, then there are several examples
of things that a raster-scan display could do that would have no
immediate counterpart on a dumb terminal: draw lines from one point to
another, display an arbitrary character from an arbitrary font at a
specific location specified in pixels, rotate a chunk of the screen,
return a mouse-click (or some other kind of pointer-selection) in window
coordinates, etc.

I think that it is a terrible mistake to rule out any of these
operations for raster displays just because there is no good equivalent
on an 24x80 character terminal.  I also think that it is not in general
possible to have the built-in window-based software fake all of these
things in "the best way possible" on the dumb terminal.  There's just no
good way to fake a drawing program on an Adm-3A, and I'd rather have the
software fail cleanly than waste a lot of time trying.  Maybe a clever
application programmer can figure out some way to fake his particular
drawing program on a dumb terminal, using the impoverished set of
operations available there, but that should be his problem and not the
Lisp implementor's problem.

So, revised proposal:

We divide features that a diplay might have into broad classes that tend
to go together: Multiple windows, Advanced cursor commands, Pixel
operations, Pointing device, Color, Multiple Fonts, etc.  Some of these
have parameters, such as the X and Y dimensions of the screen in
characters or pixels.  Each display/implemenation is required to
indicate which of these things it has and the values of its parameters,
and therefore what operations it supports.  Software will be written to
assume some set of these feature groups, and the necessary support will
be advertised with the documentation for the software.  If I want my
package to run on ANYTHING, I assume a very minimal set of support; if I
don't want to live with those restrictions, then I assume more.  The
best software providers will conditionalize their code so that if some
feature like color is present, it is used, but if it is not present they
compensate for this in some other way; others may choose not to bother
trying to cope with dumb displays.

-- Scott

∂21-Nov-84  0914	DDYER@USC-ISIB.ARPA 	Implementation strategy 
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 21 Nov 84  09:14:26 PST
Date: 21 Nov 1984 09:13:20 PST
Subject: Implementation strategy
From: Dave Dyer       <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA


Now that I've lighted the fire, I'll add my contribution to the fuel.

We have to define virtual display operations in a way that is acceptable
to the major implementations, or else the definition will simply be
rejected as brain damaged and ignored.  In particular, it should be
obvious that Symbolics isn't going to re-implement their window system
using structures.  It's just as obvious, as was pointed out, none
of the other CL implementations will have a robust and portable object
oriented system for an indeterminate time.   Therefore, we must define
something compatible with either strategy, and preferably, one that
will permit the underlying implementation to change, as object
systems become available.

What this amounts to is defining a limited object oriented system,
which maximizes information hiding but makes no commitment about
implementation.  The last time I implemented such a system, my
basic primitives looked like this.

(SCREENOP <<window>> <<operation>> &rest args)

Honest Injun, I came up with it before I ever wrote my first DEFFLAVOR!

This was implemented by a hairy macro, which expanded to structure
manipulations appropriate to the operation.  To hack efficiency,
one "operation" was :GET-HANDLER-FOR and another was :INVOKE-HANDLER-FOR.
We might also want an environment macro like 
  (WITH-SCREEN-ENVIRONMENT (VAR WINDOW) --)
Where WINDOW would be decoded (whatever that means) so that references
to VAR would know the exact type of the operand.  


The advantages of this approach are that it is easy to transform
into efficient code for most any implementation, it avoids embedding
implementation details in user code, it makes screen manipulations
easily identifiable, and it avoids polluting the global environment
with arbitrarily many names of operations.   I strongly favor this
kind of surface structure for invoking display operations.


The problem of creating an abstract syntax for defining window types
is stickier.



-------

∂21-Nov-84  1048	KACZMAREK@USC-ISIF.ARPA 	Re: Virtual Displays
Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 21 Nov 84  10:48:12 PST
Date: 21 Nov 1984 10:45:02 PST
Subject: Re: Virtual Displays
From: Tom Kaczmarek <KACZMAREK@USC-ISIF.ARPA>
To: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
cc: cl-windows@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12065345435.BABYL@CMU-CS-C.ARPA>

Typical graphic standards provide a great deal of functionality regarding
the display of lines, circles, points, raster images, and characters.  They
also provide for clipping regions, rotation of images, panning, zooming, and
scaling.  I think that a window package should be built on top of graphic
support.  We should assume the existence of font support (including producing 
bitmaps for text strings), clipping, line drawing, shading, texturing,
coloration, etc..  We should also presume high level primitives for
pointing devices ala GKS and the Siggraph Core standard.

I suggested this in an earlier message but no one seemed to pick up on it
other than to say they wanted to do all the low-level stuff.  I would like
to get a measure on how many people think that windows are at a higher
level than graphics.  I see windows as graphic structures with fairly
restrictive constraints--they are a major component of the user interface
with highly stylized behavior.  They have to be flexible enough to allow an
application programmer to mold the user interface to his liking, yet
restrictive enough so that the user is not overwhelmed by inconsistencies.
I think we ought to check with the graphics group also to get their
feelings to make sure we are not duplicating efforts.

Tom
-------

∂21-Nov-84  1250	greek@DEC-HUDSON 	Terminal features and graphic functions   
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 21 Nov 84  12:49:51 PST
Date: Wed, 21 Nov 84 15:50:10 EST
From: greek@DEC-HUDSON
Subject: Terminal features and graphic functions
To: cl-windows@su-ai

I basically agree with what Scott says about categories of features.
Perhaps we might even end up with some standard symbols in *FEATURES*
for testing by programs.  However, I'm dubious as to the patience
of developers as they try to write code that uses as many features
as possible but avoids ones not on the current terminal.  This kind
of code is difficult to write, and people just tend to write
for the lowest common denominator, or say "screw" to all but the
smartest terminals.

I think we can define virtual displays that will work pretty well
on many kinds of terminals.  If we said that all, or almost all,
operations had to work on all terminals, and forced implementors
to think of ways to do these on dumb terminals (or noop them), we
would be doing the world a favor.  As for complex graphics, that
have no counterpart on dumb terminals, perhaps we shouldn't be
treading on that ground.  Graphics is not a solved problem.

Dave - I don't understand why your statements about window 
compatibility with existing implementations leads you to believe
that the operations must be object-oriented.  What's wrong with
50 functions?  If Symbolics implements these as macros that turn
into flavorful things, no problem.  Streams are object-oriented,
structures aren't, hash tables aren't, arrays aren't.  Why start
now, when we haven't agreed on object-oriented features for CL?
(Read that as "streams aren't object...").

- Paul

∂21-Nov-84  1434	@MIT-MC:MONTALVO@MIT-OZ 	Re: Virtual Displays
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 21 Nov 84  14:34:23 PST
Date: Wed 21 Nov 84 17:31:34-EST
From: Fanya S. Montalvo <MONTALVO%MIT-OZ@MIT-MC.ARPA>
Subject: Re: Virtual Displays
To: KACZMAREK@USC-ISIF.ARPA
cc: Fahlman@CMU-CS-C.ARPA, cl-windows@SU-AI.ARPA, MONTALVO%MIT-OZ@MIT-MC.ARPA
In-Reply-To: Message from "Tom Kaczmarek <KACZMAREK@USC-ISIF.ARPA>" of Wed 21 Nov 84 10:45:02-EST

I think a lot of the issues being raised by cl-windows are relevant to
cl-graphics, and that the relationship between windows and graphics
should be discussed by cl-graphics, also.

I see windows as a subset of graphics.  Support for windows is a
specific kind of functionality that a graphics package may or may not
have.  As a subset, it's neither higher nor lower than graphics.  It
may rely on low-level primitives, but in turn, some even higher level
functionality may rely on it.

And by the way, I'm on cl-graphics also, and may have missed the
discussion of how the division was being made.  If it was already
discussed just forward the relevant messages (not too many please).

Fanya
-------

∂26-Nov-84  0717	boetje@DEC-HUDSON 	graphics, virtual displays, and terminals
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 26 Nov 84  07:16:27 PST
Date: Mon, 26 Nov 84 10:13:21 EST
From: boetje@DEC-HUDSON
Subject: graphics, virtual displays, and terminals
To: cl-windows@su-ai.arpa

On categories of features, here's one suggestion for a basic division...

Take some dumb terminals of the VT100 class. These have the ability to
position a cursor to an arbitrary cell location and write ASCII characters
This is sufficient capability support virtual displays which can have a border
and a label. The set of operations has to be restricted to manipulating text
on a cell-oriented terminal (ie, no proportional fonts). There is a suprising
amount that can be implemented on such a terminal: show arbitrary sized
displays, insert and delete characters (easier on a cell terminal), scroll
lines of text in a display, occlude displays, pick and point via cursor
manipulation and even draw horizontal and vertical lines. For a dumb terminal,
that ain't bad.

The other category then becomes the bitmapped tubes. Let's just assume they 
can do whatever we think up (although character insertion and deletion is 
harder on these terminals). It's up to us to establish a reasonable set of 
operations that should be supported.

So I'd choose two categories: the kitchen sink and the text only. The text 
only terminal is required to be cell-oriented and have the capability to 
position the terminal cursor at an arbitrary cell position. It can support all 
the capabilities needed for a screen editor. The kitchen sink terminal is 
bitmapped and can support an arbitrary level of complexity in its display 
operations. 

On the division of virtual displays and graphics...

The more I've thought about it, they really are fairly separate topics which 
have one area of overlap. Each topic has a number of basic operations and 
concepts which don't relate at all to the other. For example, a discussion of 
virtual displays gets into issues of display management which includes ideas 
such as stacking, occlusion and selection. Graphics deals a lot with 
coordinate transformation, line drawing, graphical objects and area fill. 

The one area of overlap can be neatly defined if we define the picture area of 
a virtual display to be that portion of a display inside of things like labels, 
borders and margins. The picture area is where most everything of interest 
happens in a virtual display. The picture area is also allowed to be a 
graphics viewport onto some data space (such as NDC for you GKS fans). If we 
accept this definition, then the tasks of the display committee and the 
graphics committee become a bit easier. We need to refine things such as the 
coordinate system of the virtual display. Once this is done, the graphics 
committee can concern itself with coordinate transformations, composition, 
basic operations and picking. The display committee can be concerned with 
management of virtual displays, use of a virtual display in place of a CL 
stream, and the definition of what surrounds a virtual display (labels, 
borders, margins, etc).

	Jerry