Tcl 8.7 WishList

Tcl 8.7 Wish List

This list is much more concrete than the Tcl 9.0 WishList, the wishes being more that someone should undertake the listed tasks than that someone should figure out how to do X. Also the wish might be directed more from TCT to the community at large (please assist us with getting this done) than the other way around. [the tct is an administrative body - in general, the help provided would be in terms of guiding discussion as to whether such a thing should happen, then helping get the TIP written and submitted... There is, however, the tcl maintainers, whose role is more along the lines of software maintenance of the existing code...]

Really 8.5 and 8.6 too if someone does it!

  • Expanded tutorial/docs on ttk


  • Built-in ZIP VFS
  • regexp maintainer (I would love to see more work done to improve, modernize and add feature to regexp)
    • DKF: We've got a student participating in GSoC to work on this.
    • PCRE regexp implementation [L1 ]
    • RLH: I believe that the Tcl implementation of regexp is being modernized. Do we actually want the PCRE version or the ARE version modernized? Surely we do not need nor want two packages.
    • MG: PCRE seems to be far more common everywhere else, so would probably be preferable, but breaking backwards compat by switching totally would be a nightmare; adding a -pcre switch for regexp et al is probably the most reasonable compromise to get it, but I suspect plenty will agree with you that having both is too messy.
  • Support for complex numbers and decimal numbers
    • AM: I could not resist adding these two - it seems to me right that would be best done via two separate commands - See below (after a night's sleep)
  • Unicode beyond \uFFFF.
    • DKF: I wouldn't be surprised if this is postponed to 9.0, unless we go with just converting to surrogate pairs and hoping that that's good enough. Changing the size of Tcl_UniChar is a high-impact action.
  • Asynchronous name resolution for socket
  • Adopt TclParser somehow, so that we can all get parse trees for scripts
  • binary decode/encode aes256/192/128
  • http
    • cookie handling
    • bll (2017-7-25): Make http as easy to use as php's http interface. This will include cookie, header, and environment handling, automatic redirects, and the TLS package shipped with Tcl.


  • Fixing Tk_Uid Leaks
  • winfo workarea (Something like twapi's get_desktop_workarea for all platforms
    • (From twapi help: The workarea is that area that is not covered by the taskbar and any application desktop toolbars.))
  • Run error messages through msgcat
  • Better image processing for photo
    • DKF: We've got a student participating in GSoC to work on this.
  • Standard 'Resize' event.
  • Canvas support for image photo "stippling" in addition to the bitmap image type. i.e.: image photo equivalents for -stipple bitmap, -activestipple bitmap and -disabledstipple bitmap, etc.
  • A way to find out if a character maps to a glyph in a given font. (c.f xftcharexists)

Outside the core

  • Part Done: Batteries included release!
    • DKF: What batteries to add? I'm happy with keeping tcllib out as those are things that can be in pure Tcl, but what C extensions ought to be added?
  • TkWeb
    • (compile Tk code to webpages instead of regular forms, also possibly make it Volta-ish[L2 ])


Release Policy (historic about 8.6, but relevant still)

DKF: BI releases depend on other people to put them together. ActiveTcl's an instance of this, and both tclkit and eTcl are others. But the core bits aren't likely to be done as a BI release directly since that makes things take longer as well as being more difficult for people who want stripped-down releases.

The TkWeb idea is neat, but vanishingly unlikely to happen without contributed code.

Twylite: I'd really like to see TIP #89 (Try/Catch Exception Handling in the Core) finalised and completed. Once the syntax is agreed upon I'm pretty sure it should be possible to have a pure-Tcl implementation (backwards compatible to 8.5 and 8.4) done quite quickly, leaving some time for a C implementation before the alphas/betas.

On the BI side, a lot is possible with a small alternative to the shell/application code and built-in ZIP VFS support; perhaps the latter can be prioritised?

LV: Donal, is it safe to say that just because something is on the wish list does not guarantee that feature will make it into 8.6? Traditionally, Tcl hasn't had a development team working on new features. That hasn't changed, right? Normally, if someone wants to see particular new features appear in a version, it would behoove them to participate either contributing time, money, encouragement, bribes, etc.

DKF: Correct. Contributions to make things happen (code/patches are best) will improve the chances, and all the wishes here by me are done with at least a fair chunk of "user of Tcl" perspective.

LV: Of the above list, the entry least likely to occur in Tcl 8.6 is the batteries included one, IMO. I suspect the tkweb one is another one that is too ambitious.

DKF: Hmm, I'd say that we're marginally more likely to do a BI release than tkweb-in-the-core.
Also, improved documentation for ttk is not something that needs to wait for 8.6 at all.

hypnotoad - Batteries that I would like to see (and have a kit generator all ready to build): tk, thread, sqlite, odielib (has a lot of nice 2d/3d math tools), taolib (pure tcl), udp, canvas3d, tkhtml, tdom, rl_json. On Windows I want something akin to TWAPI, but I realize TWAPI doesn't build under MSYS. I want to have tkimg, but there are some serious build issues on a couple of platforms I build with, so I end up using binaries. If we go with my Tcl build system, tk, thread, sqlite, odielib, udp, canvas, tkhtml, tdom and rl_json can be linked into a single statically linked shell or DLL.

Complex Numbers et al.

AM: My idea of supporting complex numbers and decimal numbers can be reduced to something simpler: add a command to convert an expression like "1+exp($a/$b)*$x" to "+ 1 [* [exp [/ $a $b]]] $x]". A (scripted or compiled) extension dealing with complex numbers, or arrays of numbers, if you like, can then simply implement procedures +, exp, * suitable for the "number" system and evaluate the resultant command.

Larry Smith Bolt in Gnu APL from or NARS2000 from . GNU will give you complex numbers along with all of APL's array-processing goodness, and it is already structured as a library only wanting a Tcl interface. Only real issue is changing the variable access code to use Tcl's dual-ported strings. NARS2000 will give you complex numbers along with:

  • Rational Numbers: 1r3 and 12345x
  • Variable-precision Floating Point (VFP) Numbers: 1.234v and 12v
  • Complex Numbers: 1J2 or 3.4i5 or 2ad90 or 2ar2.1 or 2au0.5
  • Quaternion Numbers: 1i2j3k4
  • Octonion Numbers: 1i2j3k4l5ij6jk7kl8

...along with all of APL's vector-processing goodness. Really seems like a big win for not a huge amount of effort. Not to mention either one will provide an APL interpreter with Tcl's extraordinary abilities with lists, strings, user-interfaces and a whole lot of other things that APL is not too good at.

There is also CAP - an APL interpreter designed to be called from C - Be careful about the links on that page, they have been hardcoded to a server that no longer exists, you need to copy the locations and change the server to I believe all of these already use utf-8 unicode.

Resize Events

DKF: There is a standard resize event. It's called <Configure>, and it's been in Tk since the beginning.

peterc: Yes and no. A resize will trigger a <Configure> event, but, not all <Configure> events are resizes. At the moment, the programmer needs to run up their own code to keep track of the size of the window manually and compare it to the current size to determine if this <Configure> is resize related or has been caused by something else. A quick search [L3 ] on Google Groups alone shows how many people ask about this. The nice thing about a <Resize> event would be that adding it wouldn't break any old code still using <Configure> methods.

DKF: Not really. Officially, there are three things that you can get a <Configure> for.

  1. A resize
  2. A reposition w.r.t. the parent widget (or the root, if a toplevel)
  3. A change of certain other settings (e.g. X border) that Tk doesn't use.

The overhead of getting resizes and repositions mixed up isn't a problem in my experience. In what way does yours vary?

peterc: An example: widget .p is a progress bar which gets resized, which triggers a <Configure>. .p reacts to the <Configure> event with code to redraw the length of the bar in accordance with its new size. This redraw itself causes a <Configure> event. Without a test for size change in some way, that's an unbreakable loop of <Configure>s. Take a look at the resolution suggestions in those Google Groups threads; in nearly all cases they boil down to "store your size beforehand and test to see if it matches with the current size when you get a <Configure>, if it does then bail". Yes, that works... but, it would be nice to remove the need for kludges like that.

DKF: Well that's a messed up progress bar. Changing the length of the bar shouldn't be a reconfiguration; it's just a repaint.

peterc: Not really. Remember, you're measuring something. You need to change the canvas contents when the size of the canvas has changed, otherwise the progress bar's meter is inaccurate. Might I ask, are there other reasons for resistance on <Resize>? Even if you can't see it helping you, is there anything about a <Resize> event which would actively hurt? I gather [L4 ] X even provides a <RequestResize> event just ripe and ready for this sort of use. (The name of the event doesn't worry me, either of <RequestResize> or <Resize> would be just fine.)

DKF: Alas, <ResizeRequest> doesn't do that. In particular, it's not sent to a window when that window changes size; it's sent when the children of that window ask (via the appropriate X11 call) to change size. Purely redrawing a widget will not cause that widget to be resized; if there's a problem, something's being done wrongly.

Tk Features

gasty: I want to see tileqt [L5 ] and tilegtk [L6 ] in the core. Also would be fine to integrate ffidl [L7 ].

ZB When talking about themes: perhaps could be possible to completely dispose of "classic" theme - that isn't aesthetic - and replace it with (quite nice) "keramik"? Actually, why keep the obsolete theme, that (most probably) isn't now used at all?

ZB I forgot: perhaps could be possible to introduce a possibility to read (ttk::)checkbutton's state by "cget"? It's perhaps the only "switch", whose state has to be read exclusively by associated variable.

bll 2017-7-25


  • In the core. Built-in to Tcl. Generally means that Tcl has C code included to support the functionality. But can also mean that the functionality is part of Tcl (does it have a man page under "Tcl Commands"?).
  • Distributed with Tcl. e.g. sqlite, tdbc::*. If present, these packages will be configured and built when the Tcl source tree is configured and built. A package require is needed to include the functionality. The package does not need to be updated synchronously with Tcl. The package may include loadable libraries.
  • Packaged separately. Distributed as a separate package. In the ideal world, these would be installed to a particular location so that a package require would be able to locate these packages without any extra work. (e.g. Python has /usr/lib/python2.7, /usr/local/python2.7/dist-packages, /usr/local/python2.7/site-packages). This will require some formal specifications as to where to install the packages/modules and how to package them properly.

I see people saying they want X "in the core". But I suspect they really want X "distributed with tcl", or simply easier to install and use without adding more paths to ::auto_path.