Article 4747 of comp.lang.tcl: Path: chemabs!malgudi.oar.net!caen!math.ohio-state.edu!howland.reston.ans.net!agate!ygdrasil.CS.Berkeley.EDU!faustus From: faustus@ygdrasil.CS.Berkeley.EDU (Wayne A. Christopher) Newsgroups: comp.lang.tcl Subject: Tcl Future Directions Session #4 Notes Date: 13 Jun 1993 17:55:31 GMT Organization: University of California, Berkeley Lines: 219 Message-ID: <1vfpmj$aeb@agate.berkeley.edu> NNTP-Posting-Host: ygdrasil.cs.berkeley.edu These are the notes from the last "future directions" session at the Tcl/Tk conference at Berkeley, June 10-11 1993. Other Berkeley people have been posting (or will post) notes for the other three sessions. The main focus of this last session was the Tk binding mechanism. Tcl Future Directions Session #4, Friday June 11 3:15-5:00 ---------------------------------------------------------- Notes taken by Wayne Christopher. Tcl/Wool -------- The first speaker in this session was Philippe Kaplan of Bull (France). He discussed the relationship between Tcl and other extension languages, in particular Wool. He mentioned a system called WTK v2, which is an integration of Wool, Tcl, and Tk. Some people made comments about the difficulty of supporting multiple extension languages in one system. Improving the Tk Binding Mechanism ---------------------------------- John Ousterhout then led a discussion of the problems with the current binding mechanism, and discussed a proposed solution. The following outline is based on his notes. Lines tagged with a - are not part of the official handout. 1. Overview Problem: * Hard to combine independently-developed bindings for widgets Solution: * Allow more than one binding to trigger for widget * Add tag-like mechanism for specifying related groups groups of bindings * Provide control over order of execution of bindings 2. Current bindings Three kinds of bindings: * Widget-specific bindings: bind .a.b.c ... * Class bindings: bind Button ... * "All" bindings: bind all ... A single binding triggers for each event * Widget-specific has priority over class * Class has priority over "all" * Within type, "most specific" binding wins: beats beats Class bindings used for default widget behavior Widget-specific bindings used for overriding, extending default behavior 3. Problems with current approach Bindings don't compose gracefully Example: add additional widget-specific actions to for buttons * bind .b foo * Replaces normal class binding for , breaks normal button behavior * Current solution: bind .b "[bind Button ]; foo" * But what if class binding changes to ? "All" bindings don't really work very well - Usually events don't get past widget and class bindings 4. Proposed solution (based on suggestion by Michael Halle) Let multiple bindings trigger on a single event * First find and trigger one widget-specific binding * Then trigger one class binding * Then trigger one "all" binding Add support for a break command to skip remaining bindings Only one binding can trigger within a group Disadvantage: not backward compatible - continue can also be used, in addition to break, to control the sequence of binding triggers (I'm not clear on exactly what this would do) - What happens if a binding calls a proc, and the proc does a break? This will be an error, but one might want it to break out of the binding sequence. - When complex sets of libraries all want to set up their own bindings, can they use break effectively? Maybe this will cause problems. - A number of comments were made that suggest that the use of break may be problematic. Add a new break-like command and TCL_ return status? Needs more thought. Provide new command to change binding tags for a widget * Change widget's class for binding purposes bind MyButton ... bind tags .b .b MyButton all - Each of the arguments after "bind tags" is a binding class, which will be searched in turn for matching bindings. - Many people made the point that it would be nicer to have these classes in a single list, instead of as separate arguments. - It might be nice to specify a list of event types, for which the list of tags are used. * Add a new independent set of bindings bind special ... bind tags .b special .b Button all * Replace all bindings for widget bind tags .b special * Make widget-specific bindings trigger after class bindings: bind tags .b Button .b all - If a list were used for the bindings rather than separate arguments, one could use "bind tags .b" to enquire about the list of binding tags, and "bind tags .b {}" to delete all the bindings. - If tags are available, maybe the "break" functionality isn't necessary here. - Maybe bindings should be able to explicitly manipulate the list of other bindings that are going to be executed, or change its order. Maybe this is a bit much. - Would it be useful to provide the same mechanism for class bindings? - Another, related idea -- all widgets have a bit of code that is executed as a "startup script" when they are created. This code could set up the bindings appropriately. - It would be useful to get default bindings in a more flexible way. If .b has no explicit bindings for , should ".b " return "", or the default bindings? - A possible concern is that if knowledgeable users try to modify scripts -- for example if they have a 2-button mouse and the author didn't think of that -- if the binding mechanism is too complex they will break things. (Is it true that bindings are the most common things that users try to hack on?) - Probably the tags mechanism isn't going to get used much. - Tags are good for program structuring because they allow one to group together sets of related behaviors. - Can something be done with an array of bindings? A widget can just maintain an array like this and call each one in succession. This can be done without any changes to the current mechanism. - Problems with events going up widget hierarchies. If there are overlays (mostly transparent windows that were mentioned earlier in the context of canvasses) will there be a problem forwarding events? - Another thing for the wish list: a Tcl-level interface to XSendEvent The overall consensus seemed to be that the proposed changes to the binding mechanism were good, but some details, such as the use of break, needed more thought. Event Priorities ---------------- Brian Smith discussed a new scheme he had developed and recently posted to comp.lang.tcl for extending the event dispatching mechanism in Tk. This was in the context of the multi-media real-time work he and Larry Rowe discussed earlier. 1. Problems When using "after", timer interval errors tend to accumulate. Events may not happen close enough to the correct time. With the current fixed priority scheme, there is not enough flexibility * Some RPC channels need tighter time bounds than others * It is hard to to round-robin among different channels 2. Solution Priority groups, e.g, RPC -> high -> Tk -> low All X events go into the Tk priority group Events in the highest priority group are processed in the normal order (I don't think I can describe the system properly in more detail -- please refer to the recent posting, or maybe Brian can fill in the details if there is interest) 3. Event loops The first step seems to be to separate the Tk event loop from the rest of Tk, as much as possible, so that it can be used in other extensions of Tcl that don't have X Future Plans ------------ Larry Rowe conducted the final discussion of the conference. 1. How to make Tcl/Tk more popular More motif compatibility -- e.g., drag and drop Mac/PC ports of Tk -- this seems the next big step. There are two ways to do this: * Pay somebody to do it and then sell it * Get a consortium to pay for a public domain effort, like the X consortium. This might cost between $200K and $300K - It people have to pay for it, it will never get popular - Some mention was made of Cayman's Galaxy system, which provides a uniform API for Mac and Windows UI's (and Motif?) We could either use their code, or do the same sort of thing - A number of people said that they might be able to raise some money for such a project -- the prospects look encouraging. The government doesn't seem to want to pay for this, however - It would help porting if Tk were restructured to hide the X dependencies a bit. It would also help if a "gadget" approach were used, with only one window per hierarchy, but this is not likely to happen soon 2. The next workshop Probably there will be one next year Might be on the East Coast Somebody needs to volunteer to organize it, but nobody seemed to be eager to do this Format questions: * restricted to ~60 people or unrestricted, or a mixture * include tutorials? introductory, advanced? * is 2 days okay, or should it be longer? (probably 3 days if tutorials, otherwise 2 days seem fine) Would it make sense to put the Tcl conference under the Usenix umbrella? Some advantages to this but not likely to happen right away Workstations should be available for demos, and for internet access Work in progress sessions? Clinic sessions ("Dr Ousterhout, my widget hurts when I do this...") If anybody has any suggestions or wants to volunteer for anything, please send mail to Larry Rowe (larry@cs.Berkeley.EDU) If anybody wants printed copies of the proceedings for $20, get in touch with Larry. Also, Larry Virden has volunteered to organize on-line availability of the papers (stay tuned)