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. *
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.