Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!hplabs!hplabsz!mayer From: mayer@hplabsz.HPL.HP.COM (Niels Mayer) Newsgroups: comp.windows.misc Subject: Re: 3D OpenLook a winner (was Re: Re^2: OSF/Motif vs. NeWS vs. SUN/Open Windows vs. ?) Message-ID: <4899@hplabsz.HPL.HP.COM> Date: 1 Mar 90 21:37:55 GMT References: <1990Feb14.201536.29437@sq.sq.com> <8130009@hpccc.HP.COM> <20372@bellcore.bellcore.com> <4885@hplabsz.HPL.HP.COM> <1990Feb28.205529.9834@intercon.com> Reply-To: mayer@hplabs.hp.com (Niels Mayer) Organization: Hewlett-Packard Labs, Software Technology Lab, Palo Alto, CA. Lines: 93 Summary: Expires: Sender: Followup-To: 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 >, 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. *