🚀 go-pugleaf

My immediate reaction to <1990Feb17.222156.21791@Solbourne.COM> was "what
if you don't like C++?" or "What if you don't *have* C++?", but on reflection
I realise this is just my basic aversion to implementing so much of the
UI at the application level.

Is there any way other than NeWS, then, to move the UI where it belongs...
in the display the user is working on?
-- 
 _--_|\  Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
/      \
\_.--._/ Xenix Support -- it's not just a job, it's an adventure!
      v  "Have you hugged your wolf today?" `-_-'

In article <TQV1CHCxds13@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>Is there any way other than NeWS, then, to move the UI where it belongs...
>in the display the user is working on?

      [ NOTE: This is posted to comp.windows.misc and
	comp.mail.multi-media. I really don't know in which
	group this kind of discussions should be placed,
	so there is no followup-line in header... ]

   All this talk about user interface seems to assume that the
application is on the same machine (or behind a moderately fast
connections) and controls directly the layout of the screen.

  What if an application is a server residing on a network (like
Internet) and is meant to be accessed from all over the globe from
all kinds of environments? Currently the server has no other
option than to use simple terminal protocol. If it wants to give
graphical information, proprietary and other special protocols
are used--tough luck for all others who would have the physical
capability to show the graphics but don't have the right
protocol. [ What non-text services are currently existing, btw?]

  The service could support OpenLook or Motif interface directly,
but doing both of them would be rather heavy on the server. Besides,
there will always be other user interfaces. I say the service shouldn't
care about details of user interface, like presentation. It should
only concentrate on providing the service and let the user decide
his/her user interface.

  In terms of P1201 I see the division of tasks between server and
user environment as follows:

	6) Application	5) Dialogue	4) Presentation ....

	   Server <--- communication --->  User
	   Program			   Agent
					   (for each	- OpenLook |
					   interface)	- Motif    | USER
							- vt100 ;) |
							- ...      |

			<- wide area ->	   <- local/fast net ->

  
   Now comes the hard question: is it possible to define an abstract
information exchange protocol at Dialogue level that would fill the
need of all or most imaginable services? What are the concepts this
protocol operates on?  *If* this was possible, it would have the
following consequences:

	-	service need to support only one interaction
		style with clients, regardless of their local
		requirements

	-	each user environment need only one User Agent
		program for all services it needs to access
		(replacement for the terminal emulation--instead
		of activating xterm, user activates xIR or
		something ;)

   There are requirements for the Dialogue level protocol:

	-	it must be able to pass text and graphics

	-	it must be extensible for new data types without
		breaking existing "xIR" programs (old versions
		would just treat unknown information types as
		byte streams--still capable of passing them on
		without knowing what it was..)

	-	information in processable form is important,
		most of the information is cut/pasted to the
		other applications anyway, edited and reformatted.
		(unrestricted, raw POSTSCRIPT will not fill this
		requirement)

  There are many services that could profit from this universal
access method. Converting the current text based services into
this format would enable them to move gracefully into multi-media
applications. The current trend seems to be to design application
specific pairs (server,user agent), each being fixed to some
specific user interface. This leads to multitude of access programs
and to a chaos--I want a single program to access most of the
information (like xterm, I activate an instance for each access).
And I wan't that program to have the user interface I like, other
people may use different interface, but the same service (e.g.
there would be different user agent for each environment, but
one user would usually use only his/her favorite version).

  Some examples of services

	-	internet name services (either DNS or X.500)

	-	mailbox service (X.400 has this P7, that would
		probably be obsolete after this? ;)

	-	traditional information services (instead of
		text only, I could finally get full documents
		with pictures, later even animations and what
		not... ;)

	-	real time conferencing services, and other
		group communication services.


  In short: I wan't a replacement for the old terminal emulation
straight jacket. I want to break out. I'm looking for the universal
information access tool for the next millenium... :-)
--
Markku Savela                         | savela@tel.vtt.fi
Technical Research Centre of Finland  |
Telecommunications Laboratory         | Markku.Savela@vtt.fi
Otakaari 7 B, SF-02150 ESPOO, Finland | savela%vtttel@router.funet.fi 

In article <4538@hemuli.tik.vtt.fi> Markku.Savela@tel.vtt.fi (Markku Savela) writes:
>	so there is no followup-line in header... ]

   Sigh, just shows I don't know all about posting. There appears to
be a "Followup-To: comp.windows.misc" in headers after I posted it.
So, be warned...
--
Markku Savela                         | savela@tel.vtt.fi
Technical Research Centre of Finland  |
Telecommunications Laboratory         | Markku.Savela@vtt.fi
Otakaari 7 B, SF-02150 ESPOO, Finland | savela%vtttel@router.funet.fi 

In <TQV1CHCxds13@ficc.uu.net>, Peter da Silva asks:
>Is there any way other than NeWS, then, to move the UI where it belongs...
>in the display the user is working on?

There's the Blit family. (Blit, Jerq, DMD5620, 630, and their
associated software -- mpx, mux, layers)

One writes the program in two parts, a host end and a terminal end.
Instead of using PostScript for the terminal end, one uses C,
cross-compile, link and download to run.  (The downloading provides a
great incentive to keep programs small) Since the terminal runs
compiled code, it can be made to run quickly.  This is A Good Idea,
since terminals tend to be CPUs with less horsepower than the host.
(of course, since various vendors want to sell you More Powerful
Machines for your desktop, they may view this sort of efficiency as A
Bad Thing) Since the terminal end is in C, one doesn't have to learn a
new language to program the display in. (I know some people would
vociferously deny that PostScript is a language:-) And one gets to use
all the tools that exist on Unix for working with C code as a
peripheral advantage.  (One could probably use some other compiled
language if one had an appropriate cross compiler -- it's just the
only cross compiler I know of for blits is a C compiler)

The graphics library has none of the fancy classing stuff and
"advanced imaging model" of NeWS -- a simple old bitblt, line and
rectangle, character drawing and a few communication primitives. It
has non-preemptive scheduling (like NeWS), and mouse tracking is done
by the terminal.  Only monochrome, unfortunately.  No subwindows -- the
theory is that subwindows are easy to do in the application, since
they're really a UI component.  None of the gazillion graphics context
options of X11.  But then, the terminal component has access to the
raw frame buffer bits, so if it wants to do something fancy, it can
just go and do it.

Each blit application is given a bytestream, it can invent its own
protocol.  Which means a bit more work, but more flexibility.  Hello
world is not a great blit example -- it can be coded entirely in the
terminal.  A better example would be something like a text editor,
where the terminal handles display of the current screen and mouse/kbd
interaction, and the host end handles the file/unix interface.

Conceptually, it's the window system I like best, and its performance
is outstanding -- it remains the only window system I know of that
runs effectively over 9600 (or slower) baud serial lines, and runs
faster on a 68000 based 1M platform than most X11 implementations on
bigger hardware. (X11R4 is faster, I think, I've seen at least one
blit fanatic work semi-contentedly on a Sun running X11:-)

The blit doesn't bother too much about look and feel issues - it
provides a fast kernel in the terminal and lets the applications worry
about the look and feel.  (I don't particularly like the trend towards
enforcement of uniform look and feel, and the megatons of marketing
hype that surrounds things like Open Look -- I always preferred the
"make it functional, make it fast, then make it pretty" axiom)

Alas, last I heard, the nicer blits cost about as much as an X
terminal (I don't like the old Blits with long-persistence green
screens, which are cheaper), and the software doesn't come with full
src unless you get Research Unix.  Its software is also somewhat, er,
hard to port (at least judging from the cussing and swearing I heard
when someone here was trying to get mux working on his brand new
5620:-) AT&T has kept the blits a well guarded secret, it would seem.

For those who want to know more about it, the main reference is:

%A Rob Pike
%T The Blit: a multiplexed graphics terminal
%J Bell Laboratories Technical Journal
%V 63
%N 8 (part 2)
%D October 1984
%P 1607-1631

The programmer's manual qualifies as the smallest window system
programming manual around -- at 12 pages, it is well under the ~45 page
MGR manual and the ~60 page X10 manual.  I don't know of it in
published form anywhere, alas.

%A Rob Pike
%T The Blit Programmer's Manual (TTY Edition)
%J Eighth Edition Unix source, /usr/blit/doc/manual
%P 1-12

%A Rob Pike
%T Window Systems Should Be Transparent
%J USENIX Computing Systems
%V 1
%N 3
%P 279-296
%D Summer 1988.

%A Rob Pike
%T A text-oriented terminal multiplexor for Blits (abstract)
%J Proceedings of the USENIX 1984 Summer Conference
%C Salt Lake City, Utah
%D June 1984
%P 173

The next two are implementation refs.  The paper on hardware/software
trade-offs is good one -- that, and a paper by Bart Locanthi in a EUUG
conference ("Fast BitBlt using asm() and cpp", I think -- I don't have
the exact ref or my copy handy) explain why the blit is so darn fast
-- someone cared about performance. :-)

%A Rob Pike
%T Graphics in overlapping bitmap layers
%J ACM Transactions on Graphics
%V 2
%N 2
%D April 1983
%P 135-160

%A Rob Pike
%A Bart Locanthi
%A John Reiser
%T Hardware/software trade-offs for bitmap graphics on the Blit
%J Software - Practice and Experience
%V 15
%N 2
%D February 1985
%P 131-151

A slightly less serious article, included here since it had Blit in
the keywords:-)

%A A.K. Dewdney
%T Computer recreations: at Bell Labs work is play
and terminal diseases ate benign
%J Scientific American
%V 253
%N 3
%D September 1985
%P 12-16
%K Blit, DMD 5620, crabs

There are also related references for sam (a nice text editor, not my
first preference, but certainly my second. It also runs under X11) and
pi (a debugger -- also in the Oct 84 Bell Labs Tech. Journal) And
there's Rob Pike's paper on "A Concurrent Window System" in Usenix
Computing Systems, v2, no.2, pp. 133-153, Spring, 1989 describing a
multithreaded window system written in NewSqeak ("a language for
communicating with mice":-)

Savela says:
I'm looking for the universal
information access tool for the next millenium...

the NISO Z39.50 protocol might be a good place to start.  I think this
American protocol is being discussed in ISO meetings now.  It was written
by the library community and is being experimented with by a number of
commercial firms and academic library systems.

Steve Cisler
Apple Library
sac@apple.com
.

In article <90Feb20.084318est.1445@smoke.cs.toronto.edu> moraes@cs.toronto.edu (Mark Moraes) writes:
>Conceptually, it's the window system I like best, and its performance
>is outstanding -- it remains the only window system I know of that
>runs effectively over 9600 (or slower) baud serial lines, and runs
>faster on a 68000 based 1M platform than most X11 implementations on
>bigger hardware. (X11R4 is faster, I think, I've seen at least one
>blit fanatic work semi-contentedly on a Sun running X11:-)

	Then again, a 1M (of non-display memory) 68000 Amiga can run X11 faster
than most suns can.  Of course, having a hardware blitter and fast lightweight
tasks doesn't hurt.

	Disclaimer: I work for Commodore.

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Common phrase heard at Amiga Devcon '89: "It's in there!"

Mark Moraes writes about the Blit:

>The programmer's manual qualifies as the smallest window system
>programming manual around -- at 12 pages, it is well under the ~45 page
>MGR manual and the ~60 page X10 manual.  I don't know of it in
>published form anywhere, alas.
>
>%A Rob Pike
>%T The Blit Programmer's Manual (TTY Edition)
>%J Eighth Edition Unix source, /usr/blit/doc/manual
>%P 1-12

It is available, as a tech report from Bell Labs.  I have a copy, and go
back and re-read it occasionally when I get too frustrated with the volumes
of X11 documentation.

Write to:

	Comp. Sci Tech. Reports
	AT&T Bell Laboratories
	Room 2C-579
	600 Mountain Ave.
	Murray Hill, NJ 07974

Ask for CSTR #121.  It's free.

Chet

-- 
Chet Ramey				"Can't you pay a grad student to 
Network Services Group			 read the manual for you?"
Case Western Reserve University			-- Bill Wisner,
chet@ins.CWRU.Edu				   	to Peter Honeyman