The papers are available in paper and electronic form from Usenix for a modest fee. The revenue generated from the sales will be used to sponsor the next workshop and other worthwhile activities of benefit to the Tcl/Tk community.
Usenix members can download the papers at no charge from http://www.usenix.org.
The copyright agreement allows authors to put up their individual papers and/or slides on their own ftp sites and we've added links to these where available.
Where authors make their slides or paper available on the web, we've added the appropriate link. If any authors see that their own link is missing, they can mail us and we'll add it.
Frank Stajano and Rob Walker
This page (c) Olivetti Research Limited 1995
Toronto, Canada, Royal York hotel
Co-sponsored by Unisys Inc. and the USENIX Association
Co-chairs:
Program Committee:
The workshop provided an international forum for discussions on Tcl/Tk research. There were over 30 presentations, including several sessions with groups of papers organized by topic with scheduled discussion periods. The sessions were:
For history it may be worth remembering that Tk 4.0 and Tcl 7.4 were officially released just a couple of days before the workshop, after a public beta cycle of six months.
Here is our hero, John, next to the megaprojector. Here and here are two views of the conference attendees; if you were there, you may even recognise some of the people! If the hall looks empty, bear in mind that this was just a "special interest" session -- during the actual conference the room was crowded.
And this last picture is just to show that the Royal York, although it looks huge in the picture above, was actually tiny compared to the surrounding skyscrapers.
Presentation of the program committee. The talks are going to be short: contrary to what was said in earlier e-mail messages, we decided to allocate 20 minutes per talk. 15 minutes speaking, rest for questions. Speaker physically removed after the time slot.
University of California, Berkeley
Speaking: Peter Liu
Tcl-Dp is a distributed programming extension to Tcl. It supports sockets, remote procedure calls, distributed objects. Shortcomings: you have to hard wire port addresses, and you have to deal with what happens when the server goes away. So we need a name server. What functionality do we need? Queries like what services do you have. Server uniqueness. Starting servers on demand to provide the illusion that they are always there. Also, the name server should be fault tolerant. Authentication is important. Xhost insufficient. We thus adopt a ticket-based system like Kerberos. The client requires a service and the name server tells it where to go (address and port); and there is a backup (or many) for the name server. List of name servers you want, as well as the primary, for backup purposes. When the primary goes down, another one becomes the primary and takes over. Current status: written in Tcl-Dp, 3500 lines. Will be included in the tcl-dp 3.3 distribution. Future extensions: Can be used for load balancing. Also: use the backup server as replicated server.
University of California, Berkeley
An improved trace for Tcl. Traces are code attached to variables. Example: an editor using incremental load and save for efficiency. Traces between the variables and the data on disc. The read trace brings the portion of the document in from disc. Checkpoint operation. Traces also work as constraints. Traces don't compose well. What if I want both persistent variables and constraints? Or multiple integrity constraints? Adam proposes a new trace where the order of firing is made explicit by the programmer. Transparent persistence is good (claim: pagemaker uses incremental saving, word doesn't [sic], so it has to put up a percentage bar while saving). Integrity constraints provide guarantees. Proof-of-concept implementation: written entirely in Tcl, slow as molasses, but works. Are these the right semantics? Feedback solicited.
Note from Adam, 1995 12 07: Source is available. [...] DMT is now implemented in the Tcl core [...]. The commentary suggested that MS Word doesn't use incremental saving and that PageMaker does. I have verified both claims. Note: Microsoft is currently building the storage manager to support incremental saving through OLE. In fact, I was on that project team this summer at Microsoft. :-)
University of Minnesota
You could call it constraints if you want. Like declarative programming. You say what the relations between your variables are and let the system enforce them. Related to constraint programming. We only maintain one way equality constraints and no special cycle solvers. Localise program control (don't concern yourself with what happens in the rest of the program.) An example is in geometry layout.Video poker application. Constraints are used to enable/disable buttons depending on the state of the application. Bet mode, play mode, payout mode. The TclProp_formula command allows you to say: when these variables change, set the value of this other variable to this expression. Then there is trigger (like trace) and an extended trace which can trace not only variables but also widget attributes etc; it sort of defines a new pseudovariable by defining commands that say what to do to read it and what to do to write it. There is also a read frequency in ms to say how often to watch it. (From the audience (was it Michael McLennan?): doing a pseudotrace with polling is really bad because you can have races. Joe admits that this should be used for user-interface tasks, like converting a widget property to a traceable thing, and not for constraint enforcing.) The code is localised to the variables and you don't really care where from in the program the change to these variables comes from. Limitations: no cycles. Only global variables. makevar is inelegant (a hack). The right thing would be to make trace (the real tcl command) trace everything. Advantages: small implementation, big gain. Can do any casino game, which is where the money is. Available now.
University of New Mexico
* Demonstration by Ben Bederson.
Live demo from an X laptop. The presentation itself is shown using Pad++ which is a canvas replacement with zoom facilities. Pad ++ is not an application, it is a substrate. Paddraw (the program he's now using) is an app that uses this pad. You can have orders of magnitude of differences in zoom factors. This is interface research. Alternative to hyperlinks etc because it lets you know where the data fits. Rendered at low resolution while drawing. Portal: sucks away a sort of view on the pad. It is like a remote control camera and the connection is both ways. similar to a symbolic link in Unix. Although I am viewing the overview, with the portal I can also do the expansion at the same time. You can also make the portal sticky so that you don't lose it if you zoom in, so you can use it as an index. They can also be used as lenses (COOL!). A lens renders the underlying data as for example a scatter plot instead of numbers. Another one is a histogram lens. More examples on lenses. Instead of entering data with the keyboard, I put another lens on top of it and use the mouse to wiggle a cursor or a dial. Also you can have image processing lenses and drag them over images. Using pad++ as a net browser. The problem with other browser is that the old pages disappear: no graphical depiction of the relationship between windows. The algorithm for layout in the pad-based browser is to put pages in alternating columns but it also leaves enough space between the columns to follow the links recursively (reminiscent of Zeno's paradox: halve it, halve the remainder again... you'll never run out). Mode (like: your canvas is in "draw circle" mode, or in "erase" mode, or "move" mode...) is difficult to implement in Tcl. So I added an optional mode to events. And then a set of active modes. Similar to tags in normal bind. Can you do portal on portal? Yes but no recursion, a portal doesn't show itself. I originally wanted to do it, if only to show the cool camera tunnel effects, but had to give up. Within the same process, different portals on different pads can look at the same data. Current research will do this over the network. Lenses: there is a message passing system. When the object is rendered it sends this to all the portals that see it and they say oh, I'll render you, and if one doesn't then it renders itself of its own. Semantic zooming: it can change the way it looks depending on the zoom level (example: this looks like a square when viewed from far away, but if you go near it you see it's actually a circle), and you can attach the callback you want.
George is the author of the table geometry manager (alternative to the packer, but still constraint- based) in the BLT toolkit; his layout editor is based on that. Widgets can span multiple rows, coluns. Transform any table into a layout editor. Uses real widgets, not placeholders. Outputs Tcl code. Layout has to be super fast or users won't accept it. Prototype used canvas and send, too slow. Need to rise above simple widgets (like word processor with paragraphs etc): need some form of high level grouping. Mega widgets make it easier to build apps. Focus on layout: need to do test drive. Ted makes it easy to edit existing designs. Package to help debug the packer (useful as teaching aid). A better BLT table.
University of Calgary
This work is a classification of other extensions. What points to bear in mind when evaluating and developing mega-widget extensions. What is a mega widget? A component that the app writer can reuse. What is a MegaWidget extension? A framework to build your own mega-widgets. So one should keep the two concepts separate while evaluating. Requirements from app writer? First the megawidget must look like a Tk widget. Create a widget command. Configure. Subcommands. Access to subcomponents (though if you have to access the subcomponents too much it smells of a bad design). Requirements for widget writer? Widget creation command, widget command, auto parsing of arguments, default behaviour. Subcommand support: create new ones, reuse/inheritance, autoparsing, namespaces and scoping. Support for options and propagating them down. Comparison of 6 extensions. There is a trade-off between two desirable tendencies: automated housekeeping (the framework does it) or flexibility (you do it).
University of Pennsylvania
Tix is a set of mega-widgets ready for use. It is based on its own OO extension to Tcl. Display of several popular widgets: combo box, balloon help, notebook, panedwindows, motif file browser, windows file browser. This stuff has good looks and gives a good first impression to users of your application. Directory browser. Tix has a lot of new widgets, very stable, improves the look and feel. Saves you from dealing with all those details. The API has to be simple even if the inside of the widget is complicated. Examples of calls to existing widgets. Tix uses a consistent set of five options: -value, -variable, - command (invoked after value has changed), -validatecmd (invoked before value is changed), -browsecmd (invoked while the user does other stuff inside the widget without affecting the value). It is important to hide the internal names of subcomponents even if you expose them for configurability. Tix uses the options database.
DSC Communications Corporation
[incr Widgets] is a set of ready-made mega-widgets written in [incr Tk]. Mega widgets are good and raise the level of gui programming. The amount of saving in code becomes substantial and raises productivity and reliability. From the user's point of view it offers a consistent look and feel. App designers with no GUI background sometimes suffer from the "angry fruit salad syndrome" (mixing all the possible variations of widget colour, size, borderwidth etc in the same window). [incr widgets] is based on [incr tcl] and [incr tk]. Gallery of [incr widgets]. Dynamic configuration is available, like adding new widgets to a paned window set, or change them from vertical to horizontal. Embedded composition: widgets have "child sites" as in Motif, where you can add extra stuff (very good idea). This is a placeholder for packing whatever else you want into it. Example: you fill an import file selector and put two extra buttons in. Tab notebook, every page is a child site. So, although this is a prewritten widget set, it can be extended using the mechanism of child sites etc. This library of widgets will be incorporated in the forthcoming [incr Tk] distribution.
SunLabs
Slides for this talk are available here .
What's happening in the Sun Tcl/Tk Project?
Outline: Tk4 update. | Name for gui builder. | Future plans. | Relationship with Java. | Hippo: Steve Uhler's web browser. | Making money. | Showcase apps. | Open discussion.
Tk 4. Finally out. Half of the Tk changes (since t=-infinity) are for Tk4. Beta: 6 months. 500-1000 bugs fixed. For comparison: Tcl 7.0/Tk 3.3: 2.5 months in beta, 2 more months for followup. Why so long? Last chance to make big changes and also added things along the way. I did conservative estimates (which told me it would take a lot) and didn't believe them (but they were right). Also arranging things after moving from Berkeley to Sun. 20-30 bugs report a day for weeks: also because the user community is much larger. Does it mean that having more users helps finding all the bugs more quickly? Or does a large software system have an infinite supply of bugs? I had 2 charts in my office: bugs outstanding and time to service. The week when they both hit the x axis I released.
Results of the "name Tk's GUI builder" non-contest (lawyers say we can't call it a contest): SpecTcl (spectacle). Several people came up with this name. They aren't winners but paid naming choice consultants. $1000 non-prize originally allocated.
What are we doing? You may think: not much visible from Sun besides Tk4. Team: 6 people. First beta for windows and mac is going to be released very late this summer. Native look & feel in early 1996. For now it has Motif look & feel. SpecTcl, first release by fall. What flavor of windows do we support? W3.1, W-NT, W95? Everything but win16. Safe Tcl security: basic, aug 1995; more, fall 1995. This will be Tcl7.5 Tk4.1. Safe interpreters yes, no resource control yet (like put limits on running time, used memory etc). Safe-tk: ensuring that you can only write on the right windows. Dynamic loading: that was easy, the hard part was versioning (require a particular version of a package).
Medium term plans: integrate the best of the existing extensions. Table geometry manager, that's really the thing Tk should have done from the beginning, instead of the packer. Socket support, probably at a simpler level than Tcl-Dp, core comms and no distributed objects. Q: once dynamic loading is available, why integrating more things in the core? This is an interesting suggestion. The only concern is that is that it must be really easy to pull the extensions in. Also it is important to know what you can count on as things that people have (for writing apps). Even with dynamic loading there is a three-level classification: things that are in the core; things that aren't in the core but you get with the standard Tcl distribution; and finally external things. More on dynamic loading: it has to work on al the architectures but we at Sun won't be able to do the testing on all the platforms ourselves. Same for sockets. What about boxes that don't have Tcp/ip? Well they just return an error. Maybe time for us to start making binary releases, probably including Solaris. We could have an online web database. How people should package up things and then risks with getting stuff from people you don't know. The Tcl group at Sun is not a huge organisation that could do support.
Application embedding, there are 2 sides to it. 1, embed a Tk app into something else. 2, embed something else into a frame widget and have the frame respond to all the window manager controls. This is the more complicated side, making Tk look like a window manager. This is important for safe-tcl so that you can redecorate stuff (like putting a red "danger" border around the window produced by the unsafe script) without the inside being able to change this.
Megawidgets, there needs to be some support for them in the system.
Another issue is name spaces, I put off doing it so far because it involves changes to the insides of the interpreter, so I planned to do it at the same time as the compiler. But maybe there is pressure to do it earlier.
Mime support.
Export megawidgets as VBXes (Visual Basic extensions)? Tcl has to be able to incorporate OCXes (OLE control extensions, sort of like VBXes but not specific to Visual Basic), but should we go the other way also? Maybe make tcl a vbx, then everybody else will write the individual gadgets. Tcl will have to support OLE. Ideally it should become "the easiest way to use OLE" (doing OLE is currently black magic).
I don't believe that you can't do megawidgets without object orientation, so I won't do oo for now.
More medium term plans: support for more images, eg jpeg. Please go ahead and write your own and submit it for inclusion, but if you do so it has to have good error handling etc. I received one where if it didn't work it just printed to stderr and exited. What about adding your own image handler? (maybe this meant dynamically) Better color management (control when to allow dithering). Dynamic unloading is complicated, we're not going to try this, at least first. Improvements to text widget: scrolling doesn't work too well yet. Tags are efficient in most cases except: if you make a lot of them, you're in trouble. Also: I want to add whatever is needed to do the world's best and most customisable web browser.
At this point John puts up the slide with the list of things in the plans and asks for a show of hands: "If you could choose, what would you like to be done first? You can vote for two things only". Results were as follows (John then put stars next to the most voted ones).
Compilation on the fly, when you get to tcl-eval. Not everything is a string, can also be turned into an integer or something else as needed. Things are turned into different representations as they are used during the course of the program. Q: will you produce a atatic checker? A: You first must have a full- cover test suite and then all these bugs would be caught too. General purpose tcl parser that people could add bits to? I tend to be bright-driven. Types? I can smell Tcl turning into C very quickly... Things will be compiled on the fly so no visible difference. Tcl-eval will compile the string before executing.
Tcl/Tk doesn't do asian fonts well. Use unicode. Things to change: regexp and font package. (Henry Spencer, author of original regexp package, later says to John: if you want to do that, get in touch first).
What about Java? Gets positive press. Very popular very rapidly. Language for executable content on the internet, both Tcl and Java want to be that. They are competitive in a sense. As languages they are very different. As you use C and shell for different things, so Java and Tcl are different. Java is a competitor with C and C++, not Tcl. This is the visual basic of the internet. VB is also a 2 language solution. Basic is the high level thing and then in C/C++ you do the VBXs. So you should do the "vbx"s in java and then combine them with tcl.
Steve Uhler did a web browser with no C code. Uses regexp to turn html into tcl script and evaluates it (10 lines). Each HTML tag has a corresponding Tcl command. It's really really extensible. It is 1/5 1/10 of the others in code size and also faster, and accessing more things at the same time. Allows tcl code to be embedded in web pages. Will support Java applets too. Released freely over the next couple of months.
Money. People must make money from Tcl so that there are more users. The visual basic model where there is a vast market in extensions (independent software houses selling VBXes). Could we make a market like this for Tcl? Make it easy to write and SELL the extensions. A web based storefront. You as developer only see the money coming in, the storefront handles credit card transactions and all that stuff. Sun to subsidise the storefront for a couple of years. Q: What would be for sale? C source? binaries? I would encourage you to sell the source, you'll see if they steal it. Price should be around 50 bucks. Keep the cost down and try and create the market. If too many controls, the market won't develop. Model used by first virtual. You get a free trial and you can say no, as long as you don't say no too often. This all depends on NOT having to recompile wish.
How can Sun make money then? Revenue sources could be: gui builder, debugger, compiler, documentation/support, your ideas? Gerald Lester suggests: making sources free but binaries chargeable.
Showcase applications (like java did). Suggestions welcome. One possibility: Web microscripting. Mix little scripts with html. Example: forms that can be validated by an algorithm at the client side before being sent back to the server. Or make mini-spreadsheets (e.g. for ordering) where at the client side they make the total of the things you've ordered as you select them. If you have other ideas then let me know.
Concern about so many extensions out there that don't interwork very well. How to fix this? What sort of certification would be required for things available at the storefront? Who has the resources to do all this?
If you have simple changes to tcl that you'd like to see, speak up now before we do the compiler. Suggestion for a showcase app: macromedia director type of content development.
Sun Microsystems Laboratories
Speaking: Ray Johnson.
These slides (and paper) are available on the web as ftp://www.smli.com/pub/tcl/doc/portable-tk.ps and ftp://www.smli.com/pub/tcl/doc/portable-tk- slides.ps
We are developing ports of Tcl/Tk to the Mac and to Windows. Most of the work is in making Tcl / Tk more portable even regardless of these specific ports. It already is very portable, it runs with most Xservers. But Tk is tied rather closely to X features in its C api. It is also tied to X in its Tcl interfaces: wm, font...
Win & mac users want a simple and powerful development tool like Tk.
Goals: we want to have the native look and feel of the target platform. Tcl/Tk must remain free so we can't use commercial packages to achieve that. Scripts should not require conditionals so if you want your script to run on X, Mac, Win then you'll have to write to the portable subset.
Schedule: win & mac ports are almost done with the motif look & feel, will be released next couple months (...Ray looks at John for approval :-)). Native look & feel early 1996. Third phase: closer integration with native platform (1 yr or more).
Various issues are analysed. Drawing model. Even how a line is drawn is different on the different platforms. Mac has a pen concept which is different from X's. Short term: emulate X calls. Long term: extend the Tk C api so that you don't have to call X flavour calls.
Native look & feel: hard to get this right if you use emulation. Need to track changing OS (Versions of windows look different from each other).
How do you wrap a system widget and get right behaviour? Different methods must be used on Win & Mac. Getting right look & feel for basic widgets is not enough: for example, the "open file" selector is a prepackaged collection of widgets that has a specific layout on the different platforms (common dialogs). We must provide a higher level interface to these dialogs and Tcl will call the one for the OS it's running on.
Binding to keys is non-portable (the command to paste is different in mac, win, unix), so a layer of indirection is required (bind to "paste", not to "control-V").
Menus are different. Different systems even put them in different places! On X and Win they are on the toplevel itself, whereas on Mac they are on the root window. Tk will have to decide where to place them based on the system.
Font names: too X specific (and ugly!) Solution: create a font object (much like image today). If you change the object, it gets updated wherever it appears. Font requests should never fail, if the font is missing then something else should be substituted. John says: the only good errors are dead errors. So let's try to get rid of things like "this font is not available" from the start by not making them possible.
Various questions about slashes for directory separation, size of integers etc.
John: we didn't add native motif widgets to the X version: we kept the Motif look-alikes that Tk always had. Who would really like to have the native ones? (show of hands: practically nobody) How many people using Tk 4.0 have found major differences with motif? (same) If you find any, let us know.
Q: the exec command? Works on NT, nowhere near working yet on mac.
Computer Graphics Laboratory, University of Waterloo, Canada
Aim: to make some given C functions (eg those from a C graphics package) accessible from Tcl. Thing to do: for each function, write a C wrapper to convert the data types from strings, and convert the C function's result into a string. What about complex data types with no correspondence? Struct & unions are easy, arrays harder. Point of the paper: trying to do this interfacing automatically instead of doing it by hand.
Examination of prior work: Wafe. A specification file (which is a Tcl script) describes the required conversions. Simple types (integer, float & c) have direct representation. Enums -> strings. Structs -> assoc arrays. Arrays -> ??? Code generation: a Tcl script (which you have to write by hand) specifies the "prototype" of the C function and, when executed, generates the C code which does the conversion of the parameters, does the error checking and, if everything goes well, calls the C function and returns the result to Tcl.
It's still a pain to write these Tcl scripts which are the specification files. So: use the header files to generate the specification files automatically. Use a parser with tables that can be extended for user defined types. Problems with pointer parameters, which could either be pointers or arrays. We use heuristics for these. C++ classes are mapped to [incr tcl] classes.
We applied this automatic approach to the OO rendering system VISION. All the heuristics guessed right. In another case (OpenInventor) there were 13 ambiguous cases, all resolved correctly by the heuristics. (like interpreting char* as a string).
NB: pointers to functions are hopeless.
Cygnus Support
Guile is the GNU extension language. Some months ago GNU decided not to use Tcl. People may have seen the Stallman posting and subsequent flame war . So what else? Another extension language - guile. A virtual machine in a C library. Can interoperate with Tcl and Scheme. Example of a scheme function containing Tcl code and how this is evaluated (calling Tcl from scheme). Then example in the reverse direction. Web browser called TkWWW. Originally written in Tcl. We took it and turned it into a scheme-extensible web browser. Very small amount of new code (1 short slide). After this, tkwww can be extended in scheme and ctax. (If I understand correctly: ctax is basically scheme with syntactic sugaring so that it looks like C -- one of the many faces of Guile.)
What's missing? Redisplay, low level, event binding.
Another project: mix Guile with Mesa, a sort of graphics/widget library. And with another one compatible with OpenGL. Waiting for a simple C interface to Tk (to be able to use the graphics but bypassing Tcl) so we use these other widgets in the meantime. From the openGl work comes out an interpreter that is suitable for 3D graphics.
Coming soon: native code compilation, networking, threads, debugger, oop, combining mesa/openGl with Tcl/Tk, bytecodes, faster Ctax, integrated programming environment.
Fun projects for Guile hackers: make tkwww into an encapsulated library, mesa/Tk integration, 3D graphics and simulations.
ICEM CFD Engineering and the University of California at Davis
A lot more complex than originally estimated. Philosophy: compile to C (for real of course, not just putting the whole script in a string). Users don't have to modify one single line, otherwise they won't buy it.
Why a compiler? Parsing is done at run time over and over again. Conversion on demand. Once converted to integer, the number can move around faster.
Why not a compiler? Types are unknown. Cute code fragment with "one" and "1". Cannot statically analyse. So we had to introduce optional declarations. Other problem: lists. Other problem: syntax. Cute examples of weird things.
Some things (like rename) cannot be handled in all cases.
Description of internals of compiler. Lots of cases handled directly, if you can't do it you eventually fall back to the interpreter. Every control structure is handled individually. for and while: variables in the test expression could change their type from integer to string from one iteration to the next!
Lots of performance figures (but too small to read from the back rows).
Future plans: provide support for [incr tcl]. Then byte-compiler. Long-term: more friendly API (eg defining the type of variables in Tcl). The way we'd do this is by making "integer" a tcl proc, that would do nothing in the interpreter but that would be recognised by the compiler.
The existing interpreters takes existing Tcl scripts and compiles them with no modification. Speedup between 5 and 15 for existing Tcl apps.
Q: what's missing before you can release it and sell it? A: nothing, it's already available in pre-release! Look at our web site. ftp://ftp.netcom.com/pub/ic/icemcfd/tclc
Support for major extensions (TclX, TclDP, [incr Tcl], expect, BLT) is in the plans and in some cases already available. The problem with extensions is what happens when they access variables.
(with computer demonstration)
Tcl/Tk is used as programming glue and GUI for a geographical database.
Spatial model - simple objects modelled (eg a fire hydrant) + composite features - all logical composition of objects - eg a highway. Spatial data types: point, line (curve), surface, solid; shared primitives. Some spatial operators: minimum enclosing rectangle, overlaps, buffer, contain, adjacent. Spatial analytical functions: area, length, perimeter, slope, transform, skeleton.
Why Tcl/Tk? easy to learn, OO extensions (use [incr Tcl]), GUI (Motif), extensions.
Client-server model. Server contains spatial model, DBMS (Empres - later will be Oracle) . Tcl is on the client side. GIS extensions: session management, message management (user msgs), GIS spatial functions, graphical viewing.
Msg management: user messages are stored in external files (not embedded in program); the system becomes language independent: for the German version, you just create another file which the local office can edit.
Graphical widget: client side - sketch (cf: Tk canvas); server side - GIS, lean display list, spatial clipping, large no. of display items; based on an extended canvas.
Harbour spatial database server & workbench for analysis and modelling.
Demo: finding a location for a community centre, given a "walking distance" and a no. of homes that we want to serve.
Demo: flood analysis - set rainfall and duration - flood Texas! See what damage was done to residential and commercial property.
Can also deal with live input - eg GPS tracking.
The University of New Mexico
('slides' done using Pad++)
Aim: to record scripts of user actions for later replay. Why? demos, regression testing. What to replay? You have to choose at what level to intercept the input. Lexical level: keystrokes, mouse events; Syntactic level: select object, push button, menu selection; Semantic action: eg rotate/delete object. Feedback to user different at each level, eg mouse moves, button sinks, object rotates. For demos, showing all the movements of the mouse is important, for regression testing it doesn't matter. Infallible record and replay is impossible: it will fail if the state of the application also depends on external resources and events or if it is sensitive to timing. So: set a restricted goal -- just be concerned with user input, ignore all other factors. How? Intercept the event stream, then replay the events later. Lexical level means intercept the lowest level X events - but are lot of problems at this level, though at least you don't have to alter the program (ie wish). Syntatic level captures events at the widget level. This is what I use. Tcl/Tk makes it easy to do this thanks to send and the introspection features in Tk.
Application has tape recorder metaphor. I can provide a comment facility for demos (like saying: "at this point, I press the mouse here, and this thing happens"); the comment appears on a popup window at the appropriate time. Two phases: the past - you need to rebind all the widgets (attaching binds that record the events as they happen) and keep track of future rebinds. Get all old bindings, save them and replace them with your own. Second phase - the future - keep track of all new binds, and new widgets created, canvases and texts. Lots of little painful details. eg, capturing % fields.
Replay is a seperate program. Potential deadlocks - event handlers may call tkWait; solution: use timeouts. Added click to terminate replay.
Complaint about hack in Tk: frame and toplevel are the same C procedure, the distinction is made based on the first letter of the command name.
Problems with scrolling and timing: the user clicks on the down arrow and keeps the button down until the desired text appears -- but this is a time dependent operation, if you change the timing it will scroll to a different place.
Munich University of Technology
* Demonstration
The acronym stands for: PLan-based User Guidance for Intelligent Navigation.
Develop a model-based user interface design environment for both the designer and the user of interactive applications. Designer support & User support.
Why model based? easy to obtain different user interfaces by using alternative layout rules formulated on basis of a styleguide. Ensure style guide conformance.
User support by generating on-line help pages in HTML and also animation sequences to show how a task should be carried out.
Example: a user interface for an ISDN phone. See layout of phone on screen, but can dynamically (@ runtime) change the layout.
Problem with online help is that the user has to know what they are looking for to some degree.
Use Tcl/Tk to visualize a set of State Transition Diagrams; communicate with the interactive app; generate dynamical on-line help pages and animation sequences (like: how do I call user such-and-such? And the mouse goes around and clicks buttons to show you). Online help pages contain: current state, actions available, how actions are performed, links to animation server and further documentation. Runtime architecture: interactive application; graph interactor, animation shell, AniSh HTTPD server, planning agent, Web browser.
Interactive app, on-line help and state transition displays all keep in step as you interact with the system.
Sun Microsystems Laboratories
* Demonstration
SpecTcl:
Preserve familiar UI paradigms where practical.
Retain power of TK's constrain based paradigm.
WYSIWYG as far as possible
be extensible
Uses a dynamic grid to provide WYSIWYG. Written entirely in Tcl (6k lines). Palette of widgets is determined automatically. Table based approach (uses George Howlett's blt_table). Uses drag and drop. Can create arbitrary rows and columns within a frame. Widgets have property sheets for standard widget configuration options and geometry management functions. Can add actions to user interface: eg "destroy %R", "exit". Can control resize behaviour of the widgets by making them "sticky" or "floating" with respect to the sides of the grid. Can give names to widgets so you can refer to them elsewhere; and attach scroll bars to widgets - automatically! All widgets are direct siblings (no artificial "frame" hierarchy) so they can be moved around easily.
Need a better way to manage property sheets - 100 options for text widgets. Implement infinite "undo" functions. Define and implement widget composition mechanism. Make defining bindings easier.
Designed so that you don't (shouldn't) ever have to touch the generated code. Won't be able to absorb code you have written if you modify the file it produces.
Charles Crowley, University of New Mexico
Michael McLennan, AT& T Bell Labs
Diverse perspectives on teaching with Tcl/Tk: Academia & Industry.
Charles Crowley: I use Scheme/Tk in introductory programming class, Tcl/Tk in software engineering(!) I want a fun language, useful as well. Tcl is easy to learn, but powerful with GUI, you can get results quickly. But it needs better extension management, modularity and megawidgets. Scheme/Tk - good in computer science category, it has closures, but good software engineering only requires "objects". Q by John: why do you need to teach CS using closures if you then say they're not useful in practice?
Joseph Konstan: 10 week course, mixed group of students. Experimenting with 3 day industrial strength course. Tcl/Tk can be taught in 75 minutes! Tk is good for teaching about UI toolkits. Students really use Tk after the class. Books making it easier. BUT Tcl cannot really be learned quickly (quoting, quoting, quoting), Tcl philosophy, debugging tools still primitive, poor prototyping tools, difficult to manage extensions. Easy to learn because it's like LISP, but accepted because it is not LISP (too many parentheses).
Michael McLennan: 3 day course on Tcl/Tk and 2 day course on [incr Tcl]. Class sizes about 16. Two kinds of people: Computer Science people, and process people. Make examples fun - build Star Trek game - 20 lines of code at a time. Make lab assignments visual and interactive - coffee shop for [incr Tcl], visual representation is important. Sources of confusion: quoting; pack - expand/fill difference; commands and keywords, eg bind; pass-by-value and pass-by-name commands (lappend, lsort); command prefix; bind with Tk4.0 adds lots more!
Teaching software architecture using Tcl/Tk extensions? No.
Would keeping Tk but switching to another lang: scheme, PERL, etc make life easier for teaching? No, need advantage of Tcl extensions. Scheme/Tk is actually bad scheme, Tk wasn't designed for it, and doesn't give a natural interface.
How will GUI builders impact teaching? Some courses split into parts, and some of the parts will not be needed. But can't really use GUI builder effectively unless you know what is going on underneath.
How about a self-taught course? Well, one of the best tools available is wish; also, the widget tour by Andrew Payne. We could beef up the widget tour to something more substantial (like hundreds of examples instead of tens of them). But this is likely to actually increase, not decrease, the demand for training because more people will become involved with Tcl.
Is it a bad thing to just teach the "How" of building UI interfaces without teaching the design principles etc? University of Minnnesota doesn't actually teach Tcl, just uses it - iterative design process, so need to get something up quickly. Rapid prototyping doesn't have to be a contradiction to good design skills. If just using Tcl for own purposes, one may not need the design skills.
University should teach a wider range of languages, not just the big few. Also different programming paradigms, eg event driven programming (wide consensus on this).
Quoting is a major problem. Would a closure or continuation mechanism help? Can mere mortals program with them? Teaching how the parser works help, but wouldn't it be helpful to have another symbol for [list ...] quoting?
Since Tcl is easy to use, unless design principles are taught it is very easy to produce a lot of spaghetti code with it.
Problem is often how to teach to non-CS students.
Universities should not be trade schools, they are there to teach people how to learn at a higher level.
Can you teach Tcl without teaching the details of the parser's quoting rules? Yes & no. Without it people tend to go through "quoting hell" a lot more. But need examples first - otherwise you put them to sleep. But you do need to put the parser explanation in at an early stage.
AT& T Bell Laboratories
The Top Ten myths about [incr Tcl]
MEGAWIDGETS: the [incr widgets] which were the object of a previous talk.
NAMESPACES (based on George Howlett's work presented at the Tcl'94 workshop): can create a namespace that contains global variables and procedures. A way of packaging up libraries and extensions. You can compose namespaces using the import command. Can import in public or protected modes. Can develop safe name spaces as well.
ENSEMBLES (based on the major/minor extension by David Herron): support complex command structures. Commands can be extended with new options. Error messages produced automatically. Includes C language API.
(masterful use of suspence at this point... and then Michael reveals his last slide)
Q/A: If you have a C++ class and an [incr Tcl] class that maps on to it, can you deal with constructors, etc properly? Yes.
Why did it take so long? I had to make changes to the core to make the namespace work. A few surgical changes to Tcl core and rather a lot more to Tk (problems with binds in namespaces).
John: so if there is a new Tcl release at least every 3 weeks we'll never see [incr Tcl] ...
Shouldn't be too hard to support [incr tcl] on the mac and win ports because there is no platform specific code. It would be trivial if Tcl had namespaces in the core.
AT& T is very much behind me in this [incr Tcl] business now.
This release: now in beta, out soon.
TipTop Software
Another object orientated extension - but different from the existing ones. A dynamic OO extension to Tcl modeled after Objective C. (He uses NeXT.) Basic functionality: access ObjC objects from the interpreter, create classes and implement methods in the interpreter. ObjTcl solves the callout problem - no interface needed. High level language seamlessly integrated with ObjC.
Introduce a "message" statement into Tcl. Follows the ObjC style of syntax. Messages are sent to objects. Tcl strings are converted to the underlying types (excl. unions and bitfields). Four new statements: class, category, method, super. Class: define a new class. Category: adds methods to an already existing class. Method: define a method implementation. Super: used to invoke a method as implemented by a superclass.
Types are required for method prototypes - but only introduced where necessary into Tcl. Multi-interpreter support, error system, debugging support (unhandled error catching, crash catching), dynamic loading & autoloading of compiled code. Can subtype compiled ObjC classes in ObjTcl. Support for InterfaceBuilder.
Objective-Tcl is available from TipTop software, see http://www.tiptop.com .
MIT Laboratory for Computer Science
ObjectTcl: Otcl. Came out of VuSystem developed by Tennenhouse's group at MIT. Computer- intensive media application, uses Tcl to combine C++ media systems. Example of graphical interface to building media processing systems. Can change objects and classes while the program is running.
Gives Flavors/CLOS-like multiple inheritance. per object specialisation, class meta-objects. Automatic method combination allows true mixins. Since it is dynamic, you can have runtime checking implemented in superclasses which can be dynamically inherited from as needed. Classes are objects too - they manage installs and provide a uniform interface. Classes are also managed by meta-class objects.
Don't change the core or duplicate Tcl. Instance variables use Tcl upvar to hidden location to access class members. Methods are simply Tcl procs. Otcl provides C interface to objects. Inheritance makes autoloading more complicated. Want autoloading at method level as well as class level. OO programming in Tcl should look like Tcl and not C++.
IXI Limited
[NB: Dean's extension is also called Object Tcl but has nothing to do with the one from MIT described in the previous talk.]
They want to perform customizations to a C++ application framework using an interpreted language. The idea is to write the real application in C++ and export commands to Tcl, as usual, but this time keeping the structure of the C++ classes. Make the C++ classes available to the interpreted language. Need to be able to support object creation and deletion; member function invocation and subclassing (virtual functions crossing language border). Two components: Class Description Language (CDL) and Otcl (Object Tcl lang). CDL supports the binding of C++ classes, it is a variant of Tcl that provides commands suitable for describing the interface of C++ classes that are exported to Otcl. CDL supports various types: int, floats, str, ptrs to objects, etc. Otcl extends Tcl with concepts of classes, objects, object creation/deletion and method invocation. Otcl seperates a class's interface from its implementation. The interface describes the publicly accessible parts of it - just declarations, no bodies. You can create new objects in Otcl regardless of whether they come from Otcl classes or C++ classes. Have class methods as well as instance methods. All attributes of a class are private, methods may be public or private. Otcl classes may inherit from C++ classes and use multiple inheritance. Conversion of C++ classes to CDL is done by hand (currently). Operator overloading is not supported.
University of Calgary
I am NOT going to talk about another object oriented extension. Instead I am going to talk about how to write extensions. Can you build extensible extensions? For example imagine an extension handling concurrency control - users want to be able to specify their own policies in that extension. More examples: have Tcl-Dp use AppleTalk as a transport protocol, have a canvas produce EPS rather than GIF. What sort of "objects" am I talking about? I am referring to objects in the sense of extensions that have a Tcl - level object-orientated API, like the Tk widgets -- nothing about inheritance! The bulk of the code is written in C/Tcl, not C++. Want to use familiar mechanisms for extensions, and be highly dynamic with the possibility of very deep customization. Extensions have core data and then subcommand handlers. Add a level of indirection at the subcommand handlers to allow extensibility and customization. Subcommands are internally held in the table, with commands to inspect and change the table from C and Tcl. Can accomplish the same as OO subclassing - add wrappers around existing subcommands, delete existing subcommands, but some loss of structure. Objects (in the Tcl sense!) can be extended in Tcl or C. But what about abstraction? Abstraction can hide relevant details, so keep abstraction but allow getting inside. Conclusions: building objects in the Tcl sense need not involve objects in the C++ sense; extensions can and should be customizable.
John Ousterhout: Tcl never started out with very high aims as a programming language, so I didn't even think about making it OO. If I were doing Tcl again then I would do it more OO than it is now, eg file handles would be objects, widgets would have set/get methods. I have concerns about inheritance, but we can still move in that direction: ie by adding namespaces. You have several different OO extensions here, I couldn't please everybody. But I could make it easier to add OO systems without having to modify the core.
Dean Sheen: Solution depends on the problem domain. If you want to use C++ & Tcl then use Object Tcl; if you need to use Objective-C then use Objective-Tcl. If you are working just in the Tcl domain then there is more choice: [incr Tcl] and MIT Object-Tcl. Depends on the object model you want to use.
Michael McLennan: Name spaces are needed in the core with: private,protected, public access; model for combining namespaces; protection hook for command access and variable access; client data for each name space.
John: Do you want objects in the core? What is a minimal useful subset? Wouldn't be able to please everyone - better to have them as dynamically loadable extensions (by those who want them). If you added an OO extension now then the widgets would stick out (or vice-versa). OO systems require inheritance and polymorphism.
Alternative to name space in the core is a C level hook into the variable access mechanism - but is likely to badly damage performance. But what does everyone mean by name spaces?
http://www-plateau.cs.berkeley.edu/
This is where the now famous "html parser in 10 lines" was first shown to the world. For history, it is reproduced below.
proc HMparse_html {html {cmd HMtest_parse}} {
regsub -all \{ $html {\& ob;} html
regsub -all \} $html {\& cb;} html
set w " \t\r\n" ;# white space
proc HMcl x {return "\[$x\]"}
set exp < (/?)([HMcl ^$w> ]+)[HMcl $w]*([HMcl ^> ]*)>
set sub "\}\n$cmd {\\2} {\\1} {\\3} \{"
regsub -all $exp $html $sub html
eval "$cmd hmstart {} {} \{ $html \}"
eval "$cmd hmstart / {} {}"
}
Larry Rowe jokingly asked: "John, does this follow the official Ousterhout coding style?"
John: "No comment..."
Larry: "Yeah, we didn't see any..."
Main focus: if we want the Tcl community to grow, people must be able to make money with Tcl and we (John and Sun) want to encourage that. How? One possibility is for Sun to sponsor a web-based storefront which would make it easy for authors to market Tcl/Tk "things". Strategy: Sun pays for the maintenance of the storefront for 2 years (so that authors that use it for distribution can be guaranteed that it will stay around for a while); after that, it either becomes successful and self-sustaining or it is closed down.
So - any ideas on that? What should this storefront actually be? How should it work? What services should be offered? What pricing policies should be followed?
John had a set of blank slides and he filled them with suggestions from the audience as the discussion went on. John appears to be pretty good at moderating and stimulating discussions such as this one.
University of Minnesota
Multimedia; one of these media may be commands. A stream of snippets of code that are synchronised with the other media. Implementation: uses Berkeley's Continuous Media Toolkit. Usual multimedia manipulators like fast forward, reverse play, etc are available on this sort of stream too. Videotaped demo of music synchronised with stick-figure animation and witty text comments.
(This was our own presentation so we didn't take notes. Here is a summary.)
The Medusa environment for networked multimedia uses Tcl to compose applications out of low-level processing blocks called modules. A medium-sized application such as a two way multi-stream videophone already uses around one hundred interworking modules, running in parallel on several host machines. In this presentation we show how we overcome the inherent complexity of such applications: to deal with parallelism we use a multi-threaded library hidden behind a single-threaded Tcl interpreter; to build higher order components than the modules we use the object oriented extension [incr Tcl]; and to exploit the variety of available input and output devices we adopt the Model-View-Controller paradigm.
The slides were followed by a 3-minute videotape showing a proof-of-concept implementation of the Model-View-Controller paradigm applied to the puzzle game Gripple. Among other things this featured a hand tracking controller (follows your hand in a video scene and draws its outline dynamically) and a speech recognition controller (lets you send instructions to the game by speaking into the microphone).
The paper is available here .
NEC USA Inc.
(This transcript comes from the "common" report -- we were still messing around with the laptop after our own presentation.)
Communication in distributed multimedia systems with mobile applications.
3-d view of information sources and sharable, synchronous workspaces.
Need to manage the integration of synchronous and asynchronous event handling.
Lack of fine-grain control of thread scheduling is a problem for synchronization.
Use Tk's update and after commands to manage synchronization.
Wish list: Separate access to tk's event loop, support for X extension events.
Cornell University
Speaker: Jonathan Swartz
They add 2 types to tcl: still and video. They can "look" at the frames and do image processing manipulations with Tcl commands. They can do for example scaling, fading, translations... Multiple stills can be combined to form a video sequence. By specifying an increasing amount of fading on successive pictures, a fade-out video can be obtained. Combined with another one in the reverse direction, this gives a cross-fade. Video editor written in Tk: the editor outputs a rivl program.
University of California, Berkeley
We should exploit the tools we have better, because many years ago they could do zippy things with a 1 MHz apple ][. Use what you have effectively. In Tkman you can add annotations and highlights to pages and they'll stay there. Reverse-compile the manual pages to get a nice printout. Use just a plain wish (no C extensions) otherwise you cut your audience by 90%. Various speedup tricks.
GE R& D Center
Aim: to restructure NBC's broadcast system. The old interface was based on CRT's. Now they want to do it with a GUI. Need a rapid tool for prototyping. Other GUI builders produce 50000 lines of someone else's code. Kevin Kenny (GE's Tcl guru) did a 20-minute user interface prototype and blew their socks off. Migration from Tcl-only prototype to a production system where various things migrate to C++, sockets, sybase, etc, but the interface stays in Tk. Protocols are all string-based.
Xerox Parc (now SunLabs)
Prelude: plug for his own Tcl book, just published. Exmh: extensible platform for mail. Simple module system so that people could extend it in neat ways. Pure wish with no extensions. Doing modular programming by convention (naming conventions rather than true namespaces). You have to deal with having many instances of an "object".
Customisation: search user's library first so that you can change the definitions. Installation sets up the dependencies from the environment. Installer has 2 parts: install.tcl (could be used in your own application) and exmh.install.
There is a link between user preferences, default, xresources and help text. For now there are three categories ("types"): boolean, choice, string. I didn't like X resources, but I ended up using them eventually. Because otherwise you can't change widget options without changing the code. Initial version used a Tcl file, but users wanted X resources. Various hacks. Hooks: call user hooks at key points. From 1200 to 24000 lines in 2 years. You can customise exmh without touching the core code.
AT& T Bell Laboratories
Wireless communications: where do you put the base stations for optimum coverage? Coloured picture of the radio coverage in a building. Others did the computations that determine the propagation of radio energy and so on. My part was doing the pretty pictures. Communication between processes using text files over pipes. I didn't want to add any C code in the user interface. The C++ generates "canvas create rectangle" commands. A few problems with canvases. I had to redo the same application for the Windows environment so, based on that experience, I'll present a comparison between Tcl and Visual Basic. Packer: better for dynamic windows that will resize, but loses over VB for easy stuff. VB has a uniform look & feel. VB is easier to learn (took me 1 week to learn VB, 6 months to learn Tcl). Vb has no canvas, pain to simulate it. Interprocess communication hard (this is probably a Windows problem, not specifically VB's). Windows gui are too hard, VB makes them almost easy. Market: VB's market and user community is 2 orders of magnitude larger than that of Tcl/Tk.
Technical University of Braunschweig
Describes scotty, which is a Tcl interpreter for network management which uses Tk's event loop but without tk (a la dpwishnotk) using a new feature in tk4. Smart agents can receive and execute scripts from other agents to do network management.
Paper available here , slides available here .
Usenix offered to sponsor this conference in the future and to make it a regular event.
We must be prepared to have a much wider audience if Tcl is going to grow to its next stage (especially with the coming Windows and Mac ports). This year we had 150 attendees. What about having 300? 500? More? Splitting the presentations into parallel threads? Having specialist sections with selected attendees? Tutorials? Maybe some on the popular extensions, given by the people who wrote them.
Conclusions: around 300 people is ok, not too many more for now. One thread is best, so everyone can follow everything. Tutorials are a good idea. In the future, the program committee for year n+1 should ideally be formed during year n and not after the end of year n's workshop.
Last updated: 1995 12 07.