🚀 go-pugleaf

In article <1990Feb28.205529.9834@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes:
>In article <4885@hplabsz.HPL.HP.COM>, mayer@hplabsz.HPL.HP.COM (Niels Mayer)
>writes:
>> "What's six lines long?"
>> 	The source to the WINTERP version of 'Hello World'.
>
>Winterp is extremely nifty, and brings to X many of the advantages of NeWS
><insert pats on the back here>, but it has one significant problem at the
>moment: it does not support multiple simultaneous connections from clients,
>and correspondingly it does not maintain more than one context.

Thanks! However, I must state that it was never my original intent to use
WINTERP as a user interface server for multiple clients... however it soon
became apparent that it could be used for NeWS-like things, and i've talked
to a handful of people that are interested in doing just that. The overall
principle I applied to WINTERP is K.I.S.S. (no, not wearing elevator-shoes,
face paint and playing teen rock anthems -- rather, Keep It Simple
Stupid)... that tactic is realistic if you consider that I have been
working on WINTERP on my own in order to build a platform for groupware
research being done in my project at HPLabs.  WINTERP's feature of a
serverized lisp listener was added because I wanted all WINTERP-based
applications to have a built-in cheap, flexible RPC mechanism for
inter-client communication. It was also the easiest way to allow Lisp input
to be processed alongside X events -- this allows you to see the X results
of your lisp input immediately, interactively.

FYI -- Last summer, we had an MIT Master's student use some parts of
WINTERP/XLISP for use in a multimedia (sound, video) control platform (tV)
for networked workstations. He was able to get multiple simultanous
connections from clients... I haven't had the time to integrate his code
back into WINTERP because I'm really supposed to be working on groupware,
and multiple simultaneous connections is peripheral to our design.

>  It's wonderful
>for playing around with MOTIF, but it doesn't look as useful for building
>the UI parts of large applications in the way that NeWS is.

I didn't have the time nor management buy-in to do anything like NeWS. I
had a fairly specific purpose in mind (a platform for the groupware
toolkit) which was generalized by the realization that WINTERP would also
serve as a good OSF/Motif application prototyping/customization/delivery
environment.

>Granted, you
>can compile WINTERP into your application, but that seems a little backward
>for a UI server...

That's actually the way I intended for WINTERP to be used. Many
applications require a customization language in order to better integrate
into the user's and/or vendor's environment -- examples of such
applications include gnuemacs, autoCAD, and our groupware toolkit
(Strudel). The customization language can be used to add or alter
functionality, or to radically alter the "look" of the application. For an
exampe of the latter, you could imagine an e-mail application in which the
mail primitives are implemented in C but accessible from the lisp
interpreter. By combining the mail primitives with the UI primitives in
WINTERP you could provide a number of "canned" interface styles that the
user can select, modify via programming-by-example, etc. Specifically, one
could provide "profiles" for an X11r3-xmh style mailer which is all button
based, or an X11r4-xmh style which is pulldown menu based.

Many applications already provide a weak UI interpreter for the purposes of
UI customization. Most X11 window managers have code to allow you to build
up your own menus and attach menu entries to w.m. or system functionality.
The X11r4 xmh allows you to specify a list of buttons (via Xdefaults) to
handle common operations that would be tedious to activate via the default
pulldown menus.  UIL-based applications extend and generalize that kind of
customizability. However, such customizability is "weak" because the
"languages" used aren't real programming languages, and therefore can't
handle application-state dependent dialogues.

I hope this clarifies things a bit....

PS: w/r/t the statement "but that seems a little backward for a UI
server"...... my comments on this would involve further digression from the
subject line. Let me just say that I'm not convinced that the UI server
model (that is, a UIMS for multiple applications) is entirely appropriate
(though it does have obvious advantages). I like the fact that the X server
is robust and relatively simple. I can make a programming error in an
application I'm writing and not wedge the entire server (and thereby wedge
all my other apps). Switching between different dynamically loaded shared
UI toolkit library implementations (using the same programmatic interface
definition/protocol) can achieve the same effect as downloading code into a
NeWS server. Yet, you can still maintain the autonomy and memory-protection
aspects of running multiple separate unix processes. As a programmer, I
find such aspects of usage extremely important.

-------------------------------------------------------------------------------
	    Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com
		  Human-Computer Interaction Department
		       Hewlett-Packard Laboratories
			      Palo Alto, CA.
				   *