Article 4726 of comp.lang.tcl: Path: chemabs!malgudi.oar.net!caen!nigel.msen.com!sdd.hp.com!ux1.cso.uiuc.edu!howland.reston.ans.net!agate!agate!msilva From: msilva@mercenary.CS.Berkeley.EDU (Mario J. Silva) Newsgroups: comp.lang.tcl Subject: notes on tcl/tk's wkshop 1st session on future directions Date: 11 Jun 93 09:16:13 Organization: UC Berkeley, CS Division Lines: 232 Message-ID: <MSILVA.93Jun11091613@mercenary.CS.Berkeley.EDU> NNTP-Posting-Host: mercenary.cs.berkeley.edu [Below are my notes of the 1st session on "Future directions for Tcl/Tk" that took place yesterday. Other UC Berkeley students will submit their notes for the other 3 sessions in subsequent postings. I hope these notes will stimulate the continuation of the very productive discussions we had during the wkshop. For those who didn't come, don't miss it next year! These sessions were conducted by Prof. John Ousterhout. Part of the text is taken from John Ousterhout's slides, part are my annotations of what was being discussed. I've typed this in the emacs outline mode. If you look only at the headers, you'll see in most cases the text that was being discussesd at the moment on John's viewgraphs. The text inside are my annotations. Mario ] -*- outline -*- * Tcl/Tk wkshop; summary of "future directions" sessions ====================================================== First session was an introduction by J.O. of topics for discussion. Idea was to identify the most important areas for improvement (what are the biggest current problems?) and later discuss possible solutions. * This was the initial list of topics and reactions: ** 1. Managing extentions how to make it easy to mix & match various extensions to Tcl & Tk (both C code and Tcl Scripts) Very Important! ** 2. Restricting scripts (security, etc.) goal is to have a live discussion of what has been going on the secure-tcl mailing list Important! ** 3. Generalized Tk Bindings we all know that bindings don't extend well, discuss possible solns. Important! ** 4. Better object management facilities We already had 1 hour of presentations of religious beliefs about this issue in the morning. Everybody was too tired to react to the proposal of the topic. ** 5. Internationalization John briefly described recent wk by Rob Pike presented at Usenix. From the description, it seemed that his extension would be incompatible w/ iso8859. Tk now almost completely supports 8-bit characters, ie, the European char sets. Audience in general didn't seem to be willing to discuss of I18n issues; no experts present. ** 6. Procedure library for Tk Building a library of commonly used widgets, continuing the long discussion has been going on the newsgroup. * Additional topics The purpose of this session was not to discuss the topics above but to enumerate the topics for discussion in the following sessions. Below is my understanding of what addtional topics were proposed by the audience. ** 7. Events *** managing event loops problem is that every app wants other apps to use their event loop. Few can be easily plugged into other event loops. *** threads how to incoporate tcl/tk in a thread package? according to J.O. most of Tcl/Tk is ready to be used within a thread package. However, he acknowledged that there are still a few globals. *** event priorities requested possibility of prioritizing execution of pending events *** user-extensible event types so far TkDoOneEvent has flags to indicate request for processing of timer events, file events, X events. A finer grain is required. *** portability of the event model to other platforms? *** support for other input devices tablets, etc. currently people open the device of the serial line where the device is and process the raw input. Higher-level support for these devices is required. *** file handlers buffering ** 8. send *** multiple transport mechanisms people want to use send w/o caring which transport mechanism (tk_send, tclTCP, tclDP, ...) is being used do deliver messages to remote applications. *** asynchronous sends Current send is synchronous. Problem w/ asynch is how to handle errors, ie, how to notify the user of a client program of an execution error on a command sent to a remote server. *** service protocol (oo binding) Session management facilities should be available. An application should be able to send messages to a service (e.g, the DEBUGGER) and have the session manager 1. decide which app to invoke for the service (e.g, a tcl-based dbx) 2. automatically activate the app, if not started *** security this was not the right time to discuss it, but a small brainstorm took place here. summary of discussion: 1. better wait for what security mech will become widely available for X and use it (kerberos seems to be the current direction) 2. there are additional issues that have to be addressed, like restricting access to low-level commands. For example, a system may have a tcl i/f where low level commands are used to perform individual operations that are potentially dangerous when executed in a particular order. Users should be able to invoke only high-level commands that execute pre-defined sequences of the low-level commands that are known to be safe. ** 9. Binary data issue is converting binary data as it arrives from a connection into strings that can be manipulated by Tcl. This looks like a simple problem, but there is the issue of at what point is the conversion done. ** 10. Canvases There was a long wish list for canvas. I'm not sure if I catched them all. *** partial fills of objects suggestion: the canvas widget has an internal, undocumented, protocol. That common protocol is used to control the various types of objects within the canvas. An extension could be made by adding new types repecting that protocol *** C access to internals people want to manipulate the canvas w/o going through Tcl_Eval *** unmapping window mappings YESSS! *** geometry manager YESSS! *** adjusting coordinates *** indirect points hard to understand *** transformations associated with individual canvas items *** 3D canvas There were requests for a PHIGS canvas or a PEX canvas or simply a canvas w/ 3 coordinates. J.O. guaranteed he would not do it. *** support for multiple resolutions don't need to draw all the points in a low-resolution display. *** writable bitmaps *** active Foregroud & Background for canvases *** multiple windows for displaying the same canvas would like to show different viewports on the same canvas on different windows. people want that for the text widget too. Mario Jorge Silva msilva@cs.Berkeley.EDU University of California Berkeley Ph: +1(510)642-8248 Computer Science Division, 571 Evans Hall Fax: +1(510)642-5775 Berkeley CA 94720