mayer@hplabsz.HPL.HP.COM (Niels Mayer) (06/28/90)
In article <BRENNAN.90Jun26195002@bach.rtp.dg.com> brennan@rtp.dg.com (Dave Brennan) writes: >Recently the idea came up that menus and a button panel would help new >users learn Emacs. Current application place fixed operations like >find-file, print, help, etc., in menus accessable from a menu bar, leaving >mode/window specific buttons for placement in a button panel. Generally, >changing the menus on a user is a Bad thing to do. However, changing the >buttons on the button panel shouldn't cause too much confusion (especially >if the user can manually change the buttons displayed via an Motif-like >option menu at the top of the button panel). Something like this would be doable in my WINTERP environment, available for free via anonymous ftp from expo.lcs.mit.edu. You might think of WINTERP as a OSF/Motif-based gnuemacs-like environment in that you can build applications by using a mini-lisp interpreter to "tie together" user-interface objects defined by the OSF/Motif widget set. WINTERP contains a serverized lisp listener, which means that you could have emacs-lisp and winterp-lisp communicating with each other in order to exchange information and update state -- in the case of emacs, you'd use a modified emacsclient that would allow you to send emacs-lisp to gnuemacs' lisp-listener. In the case of WINTERP, the only outside access to the lisp-listener is via a TCP-based socket and a simple client 'wl', similar to 'emacsclient' but allows sending of lisp s-expressions from the command-line... Here's my standard blurb on WINTERP, extracted from my Xhibition '90 paper "Winterp: An object-oriented, rapid prototyping, development and delivery environment for building extensible applications with the OSF/Motif UI Toolkit." -------------------- WINTERP is a Widget INTERPreter, an application development environment enabling rapid prototyping of graphical user-interfaces (UI) through the interactive programmatic manipulation of user interface objects and their attached actions. The interpreter, based on David Betz's XLISP, provides an interface to the X11 toolkit Intrinsics (Xtk), the OSF/Motif widget set, primitives for collecting data from UN*X processes, and facilities for interacting with other UN*X processes. These features enable WINTERP to support rapid prototyping of applications using multi-window graphical user-interfaces by allowing the user to interactively change both the appearance and functionality. In addition to prototyping applications and experimenting with UI layout, WINTERP is also an excellent platform for delivering applications requiring an embedded customization language. Traditional X applications based on the Xtoolkit allow users to alter X resources to tailor application UI parameters such as fonts, colors, window sizes, etc. Motif's User Interface Language (UIL) extends that level of customization by allowing the layout of the application's UI widgets to be tailored. As a language, UIL has the expressive power to describe the layout of static UI forms, but has none of the control flow and data handling constructs associated with real programming languages. A programming language is needed to support the full range of requirements needed by User Interface Management Systems (UIMS); to describe dynamic, data-driven UI forms, and to model user/application dialog. WINTERP provides such an embedded programming language allowing tailoring of the UI's static and dynamic layout, UI-to-application dialogue, and application functionality. WINTERP is thus an interactive ``language based'' user-interface development environment (UIDE). WINTERP is not a UIMS -- it provides UI primitives and a high-level language to support a wide variety of UI-to-application partitionings\footnote{Examples of such UI-to-application partitioning that can be implemented in WINTERP include Smalltalk's Model-View-Controller paradigm, state transition machines, event grammars, etc.} that is characteristic of the UIMS approach. WINTERP is designed to allow the programmer to evolve a suitable UIMS model that is appropriate for extending and customizing a particular application. WINTERP is also designed to support direct manipulation UI building. The current version contains a useful primitive for ``direct manipulation programming'' with widget-objects. An environment similar to WINTERP's already exists in the GNUEMACS text editor --- in fact, WINTERP is strongly influenced by GNUEMACS' successful design. In GNUEMACS, a mini-Lisp interpreter is used to extend the editor to provide text-browser style interfaces to a number of UN*X applications (e.g. e-mail user agents, directory browsers, debuggers, etc). Whereas GNUEMACS enables programmers to create new applications by tying together C-implemented primitives that operate on first-class types providing textual interfaces (buffers, windows), WINTERP's ties together operations on graphical user-interface objects implemented by the Motif widgets. Both achieve a high degree of customizability that is common for systems implemented in Lisp, while still attaining the speed of execution and (relatively) small size associated with C-implemented applications. WINTERP was initially made public on the MIT X Consortium's X11r4 ``contrib'' distribution; up-to-date versions are available via anonymous ftp from a number of Internet sites including expo.lcs.mit.edu. WINTERP is quite robust and bug-free, it is in active use by a number of research projects at HP Labs, and is also being used by companies and universities worldwide. WINTERP was designed to be portable -- it runs on most ``standard'' UN*X platforms without porting. A number of improvements have already been contributed by WINTERP's user group since WINTERP initial public release; submitted improvements will be included in publicly available updates of WINTERP. You may obtain the current source, documentation, and examples via anonymous ftp from host expo.lcs.mit.edu: in directory contrib/winterp you will find the compress(1)'d tar(1) file winterp.tar.Z. If you do not have Internet access you may request the source code to be mailed to you by sending a message to winterp-source%hplnpm@hplabs.hp.com or hplabs!hplnpm!winterp-source. There is also a mailing list for WINTERP-related announcements and discussions. To get added to the list, send mail to winterp-request%hplnpm@hplabs.hp.com or hplabs!hplnpm!winterp-request. ------------------------------------------------------------------------------- Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com Human-Computer Interaction Department Hewlett-Packard Laboratories Palo Alto, CA. *
mayer@hplabsz.HPL.HP.COM (Niels Mayer) (06/28/90)
In article <9006270221.AA02832@sugar-bombs.ai.mit.edu> rms@AI.MIT.EDU writes: >If you are interested in working on x-related features, please plan >on using only the free X facilities, and not proprietary software such >as Motif. While I'm usually the first person to criticize the OSF (on its shoot-yerself-in-the-foot-licencing policies, technology compromises, and general wanna-be-AT&T'ness) I would like to put on my HP hat for a moment and mention that OSF/Motif is (or will be) a standard part of the Un*x OS supplied by major computer industry players such as Hewlett-Packard, HP/Apollo, DEC, IBM, MIPS, Data General, etc. (apologies to ommitted companies...) With OSF/Motif becoming a defacto standard does the "proprietariness" of OSF/Motif matter?? Afterall, gnuemacs runs on a number of proprietary unix systems, as well DEC's proprietary VMS. What's the difference between linking in libXm.a and whatever proprietary unix libraries that gnuemacs uses? None of those Un*xes and libraries fall under the gnu licencing policies, and all follow various greed-oriented licencing policies that run counter to the orientation of FSF. It seems like the implicit policy in gnuemacs and other FSF software is to support systems following defacto standards such that FSF software can run on the widest variety of systems and be supported by the widest number of people willing to hack/improve/contribute to the software effort. Unix is not free (yet) and this makes the "proprietary software" argument rather fuzzy. >X is an important piece of free software, so we (the FSF) can feel >only alarm when attempts are made to supplant parts of it with >proprietary software. In effect, there is a danger that parts of X >will cease to be free. While the free toolkits and window managers >would still exist, that would not count for much if they could not >make actual X applications work. IMHO, the free toolkits do not have sufficient functionality, lack good documentation, have an ugly-look and feel, are incompatible with PM, etc. W/r/t window managers, the only issue should be ICCCM-compliance (a rather nebulous thing) because that is a standard for compatibility. It would be silly to write even a motif application that won't work without the motif window manager. ------------------------------------------------------------------------------ Disclaimer: I am not speaking as an HP representative. I'm not even speaking for myself. The conspiracy is speaking for me. Yeah, that's it. ------------------------------------------------------------------------------- Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com Human-Computer Interaction Department Hewlett-Packard Laboratories Palo Alto, CA. *
paj@mrcu (Paul Johnson) (07/02/90)
>In article <525@argus.mrcu> paj@mrcu (Paul Johnson [Me]) writes: > > 1) Application control (mouse based editing commands). For this we > want popup menus [....] >By menus do you mean popup menus, or menus from a menu bar? [...] I had both in mind: if there is a function popup-menu-at-mouse which could be bound to (say) the right hand mouse button for most of the display and (with a different argument) to the left hand button for a small area then a menu bar can be built. Paul. -- Paul Johnson UUCP: <world>!mcvax!ukc!gec-mrc!paj --------------------------------!-------------------------|------------------- GEC-Marconi Research is not | Telex: 995016 GECRES G | Tel: +44 245 73331 responsible for my opinions. | Inet: paj@uk.co.gec-mrc | Fax: +44 245 75244
rick@cstr.ed.ac.uk (Rick Innis) (07/02/90)
It should be possible to implement such a beast using a combination of GWM and Epoch, though I've no idea how easy it would be. The Epoch manual certainly suggests that this is the case, though. --Rick.
carroll@m.cs.uiuc.edu (07/03/90)
It is possible to build a menu system using Epoch & GWM: We've done it.
And someday, hahaha, we'll have the code in shape to release. But actually,
it's not that hard - two different people have done it, and neither was a
Lisp hacker, or even an experienced Elisp programmer. If someone _really_
wants this, and is willing to take fragile code, I might be able to arrange
something.
Alan M. Carroll Barbara/Marilyn in '92 :
carroll@cs.uiuc.edu + This time, why not choose the better halves?
Epoch Development Team
CS Grad / U of Ill @ Urbana ...{ucbvax,pur-ee,convex}!cs.uiuc.edu!carroll