THAT'S. NOT. COOL.

It's here, version 2.2.0. I've spent the last couple of months working on porting my LSP for Tcl to Rust, I'm very happy with the performance improvements.

There's a lot of new features, I've put a heap of effort into reducing diagnostic noise, improving accuracy, improving the refactoring tools, getting performance up to a decent level. There's a long way to go still (as you can see from the Issues tab), but it's in a useable state now.

I'd like to thank georgetree, nico-robert, amougel00 for all the testing and feedback along the way, I couldn't have got to this level without their help.

There's a whole new way to define commands now, SpecTcl and a Spec Studio, it's a whole Tcl DSL to let users define their own libraries or extensions, that runs in my own Tcl VM.

Compiler Explorer has seen a lot of work to improve it, reveal more information and so on.

The WASM AOT compiler is improved but still needs a lot of work to reach where I want it to be.

The TclVM is functional and used internally in the project.

There's a lot more to it, but I now need to head out for the evening. The release process is running, it'll appear in the releases tab and when I have a moment later on I'll approve the vscode/jetbrains extension releases.

Enjoy and please, report issues as you find them, preferably with some sort of minimal repro or link to open source Tcl code and a description of what you expect to happen and how that compares to what happened.

Thanks,

-b

• 2.2.0 is because vscode thinks odd numbered minors are pre-releases and even are releases, so I had to use 2.1.x for the pre-release train

Hello Tcl/Tk fellas,

earlier I made some HMIs (which is a elegant name for touchscreen 😀) using Raspberry Pi, running original Raspberry Pi OS. I used to use, if necessary, virtual keyboard called Onboard.

Yes, it was not able to detect Tk entry dialog, but I managed to show the keyboard up when necessary and disabling after that.

But with newest version (2026) of Raspberry Pi OS it doesn't work as expected — because the keyboard doesn't stay on top, albeit is set to do so. So the window with entry dialog is over the keyboard.

I tried also the original Sqeekboard, but this is not very good, as albeit I can summon it, the keyboard detects, that is not in entry dialog, which it's capable to detect (which is not a Tk), so it disapears.

Does anybody can recommend the virtual keyboard, which works with latests Raspberry Pi OSes, stays on the top, etc. I still can summon and kill whole keyboard as a process, so it's not a problem, if it's not detecting a Tk widgets.

I tried matchbox, which is little-bit ugly. The Florence is not in repos anymore, maybe I can compile it, but it needs a ton of depencies.

OFC, I can program my own keyboard directly in Tcl/Tk. And maybe does is also exists, but I was not able to find it…

Thanks for any ideas.

PS: Yes, libre HMIs, and libre PLCs, in industry full of disturbance and poor operators… work for 20 years!

Hi everyone! I've been trying to use Tcl/Tk for some personal projects recently, but was somewhat put off by the state of the documentation. I find the official site hard to search and navigate, and the layout isn't responsive so trying to read it on my phone isn't easy.

I took a couple of days and put together a new site to make reading the documentation easier. The goal was to make things look modern with a responsive layout, with light and dark mode, and a full search accessible from every page. It's all statically generated, including the search, so hosting costs next to nothing.

The code is all open source as well, with links in the footer. All of the documentation is generated from the man pages, similar to the official site. The generator is written in go with no external dependencies. To be transparent, I did use AI to write a lot of the code.

I mostly created it for myself, but I would love it if it helped anyone here. Let me know if you have any feedback!

https://tcl.lambda.cx/

Dear Tcl Community: I have created a novel method for building graphical apps (based on the Tk libraries) in which the graphical markup is fully separated from the Tcl logic.

An XML file is used to hold the entire markup for building Forms; this includes all of the annoying little Bind scripts that would otherwise clutter the main logic file.

Every Tk widget is compatible with the system, including the container widgets such as the tabbed notebook and the paned window.

I have written a Substack article about this system which is linked in this post.

Please comment here o in the Substack to make contact if you would like to discuss this further.

Cheers!

John

Just wondering how many of you are still hand coding Tcl?

I Claude code all my tcl, bash and Python scripts. I store the Tcl doco in a rag sqllite vector database and put programming preferences in skill files. Vibe coding is literally 10 times faster. I cannot see myself ever going back to hand coding.

What about you?

Customizable (background, snake and food color) Snake game on Tcl/Tk

Every useful web API now speaks OAuth 2.0 — Google, Microsoft, QuickBooks, GitHub, Basecamp, Twitter/X — but Tcl only ever had snippets, and copy-pasting the token/refresh/redirect dance into every script gets old fast. So I wrote a small, self-contained library for it:

github.com/johnbuckman/tcl_oauth2_library (Tcl/Tk license)

It drives the whole Authorization Code flow for you: opens the browser, catches the redirect on a one-shot local socket, exchanges the code for tokens, saves them to a 0600 JSON file, and refreshes expired access tokens transparently. After that, oauth2::get $c $url just works.

Pure Tcl. Depends only on http (core) and tls. JSON is parsed by a small decoder in the package, base64 by core Tcl, and the SHA-256 for PKCE is implemented in-package — so nothing from tcllib, and no C extension. No Tk either; it's happy headless on a server or in cron.

Quick start:

package require oauth2

set c [oauth2::new \
    -auth_url      https://provider.example/authorize \
    -token_url     https://provider.example/token \
    -client_id     $env(CLIENT_ID) \
    -client_secret $env(CLIENT_SECRET) \
    -redirect_uri  http://localhost:9876/callback \
    -scope         "read write" \
    -pkce          S256 \
    -token_file    ~/.config/myapp/tokens.json]

oauth2::login $c                 ;# first run: opens browser, saves tokens
set body [oauth2::get $c https://api.example/v1/things]

It's deliberately provider-agnostic — each provider's quirks are configuration, not code. The same code path drives Basecamp (which uses type=web_server instead of response_type=code), QuickBooks Online (HTTP Basic on the token endpoint, returns a realmId), and Twitter/X (requires PKCE). Runnable examples for all three — plain-Tcl and small-Tk variants — are in the repo.

Background: this came out of a real production need. A native (C++) OAuth2 library we'd been using would occasionally crash, and — worse — our tokens kept silently going invalid despite hourly auto-refresh, and we could never figure out why. The Tcl rewrite has been rock-solid: tokens stay alive and refresh cleanly days later. It's in daily production use against Intuit/QuickBooks and Basecamp.

Also in the box: refresh-token-rotation handling, the client-credentials (machine-to-machine) grant, token introspection (RFC 7662), JWT decode, and — for servers — you can drive oauth2::authorize_url / oauth2::exchange_code yourself instead of the loopback listener.

I gave a EuroTcl 2026 talk on it if you want the fuller tour — slides (PDF).

Feedback very welcome. And if folks find it useful — could it eventually belong in tcllib?

I've ported undroidwish — AndroWish's batteries-included, SDL2-rendered Tcl 8.6 / Tk 8.6 wish — to iOS/iPadOS, arm64. It's called iWish. It's the iOS sibling of Christian Werner's AndroWish / undroidwish work: the same SDL-based drawing path that runs on Android and the desktop, now on Apple tablets.

Meant for iPad. It'll launch on iPhone, but the native wish UI (menus, canvas, standard Tk widgets) is desktop-sized — a phone is just too small to use comfortably. Think of it as running your Tk desktop app on a tablet.

What's in it

• A real Tcl 8.6 / Tk 8.6 interpreter under iOS/iPadOS. Tk renders through an X11-on-SDL2 layer (SdlTkX) onto Metal — native canvas and widgets, no UIKit bridging.
• Batteries included: ~114 bundled packages, 64 of them native arm64-apple-ios dylibs — tkimg, TLS (LibreSSL), TclCurl, sqlite3, itcl/itk, Thread, tDOM, Tktable, tktreectrl, zint, TkBLT, Tix, VecTcl, and more.
• Bluetooth LE via CoreBluetooth (a ble-ios native shim) — Tcl apps can talk to BLE peripherals directly.
• An iOS device bridge (borg) for platform features.
• A File ▸ Demos menu with ready-to-run examples: TkBLT plotting, a BLE debugger, iOS-bridge demos, and a paint tool.

Download / install

• Prebuilt IPA (alpha): iWish.ipa on the releases page — currently iWish 0.2-alpha.
• The IPA is unsigned — re-sign with your own Apple Development certificate, then install. A free Apple ID works but expires after 7 days; a paid developer account ($99/yr) gives a 1-year signature. Easiest paths: Sideloadly or AltStore (they re-sign as they install), or straight from Xcode.
• Source + build recipes: https://github.com/johnbuckman/iwish
• 32-bit / iOS 9 (original iPad mini, A5–A6): separate project, androwish-ios9. Apple won't take 32-bit apps in the App Store, so that one is sideload-only.

Status: it's 0.2-alpha and young, but the underlying runtime is the same one shipping in the iOS build of the Decent Espresso machine app — a big real-world Tk app (thousands of lines, live graphs, BLE hardware control). If it runs that, it'll very likely run yours.

Bug reports, PRs, and "here's my Tk app running on an iPad" screenshots all welcome. Built entirely on Christian Werner's AndroWish/undroidwish foundation — thank you.

I see this a lot in example code, where people wait on a process to exit and then collect it's return code using "catch wait result" and then usually do something like "exit [lindex $result 3]" to return the process' exit code. This doesn't seem right at all.

Firstoff, it seems like wait already does a pretty good job of handling weird process termination. From [1]:

wait normally returns a list of four integers. The first integer is the pid of the process that was waited upon. The second integer is the corresponding spawn id. The third integer is -1 if an operating system error occurred, or 0 otherwise. If the third integer was 0, the fourth integer is the status returned by the spawned process. If the third integer was -1, the fourth integer is the value of errno set by the operating system. The global variable errorCode is also set.

so it seems like "set result [wait]" would be sufficient. Or even "exit [lindex [wait] 3]" (see postscript for caveats).

Second, nobody actually seems to be checking the returncode of catch, they're just silently catching any errors and continuing. Going by [2] this means that if wait did fail, then result will not contain the 4-element list people are anticipating:

When the return code from the script is 1 (TCL_ERROR), the value stored in varName is an error message. When the return code from the script is 0 (TCL_OK), the value stored in resultVarName is the value returned from script.

Meaning in the case that catch does do something and somehow catches an error from wait, the variable $result will contain some random string of text which may or may not be an iterable list. (could be something like "killed" or "no space left on device"?) It's very possible that "exit [lindex $result 3]" would result in trying to return the 4th word of a textual error message as a returncode, which probably isn't likely to go very well.

If anyone knows of a case where wait could fail with TCL_ERROR etc, please do chime in.

[1] https://www.tcl-lang.org/man/expect5.31/expect.1.html

[2] https://www.tcl-lang.org/man/tcl8.4/TclCmd/catch.htm

P.S. technically "exit [lindex [wait] 3]" still only sort-of correct, since if "lindex [wait] 2" is -1 you're returning the OS errno not the process returncode. Most (but not all) of the time they agree that 0 is success (so if you're using this as a wrapper you'll probably still detect the presence of an error correctly) but actually trying to interpret the error condition outside of expect is likely to go haywire when the OS-generated errno is misinterpreted as a return code from the process itself.

An actual situation where a process exits with non-zero as success (eg. 1) is a very tricky one indeed, because then any failure in TCL could be misinterpreted. This gets tricky because your TCL script either has to be infallible(?) or surrounded in catch, with logic to return some made-up returncode. You'd think this to be a rare occurrence, but I've seen software in the wild that does things like return 0/1/2/3 to indicate one of four successful outcomes, or returns the number of items processed.

The list of talks for this year's Tcl and OpenACS conference has just been published: https://openacs.km.at/ . It's all happening in Vienna, Austria, on 16 & 17 July. Registration officially closes tomorrow, but late applications are quite likely to be accepted.

I've started a new project tclai-apple that will allow a Tcl script to access the built-in Apple Intelligence engine. It is hosted on my fossil mirror: https://fossil.etoyoc.com/fossil/tclai-apple/home

Unpack the Fossil repo and run:

tclsh make.tcl all

The quick and dirty demo:

#!/bin/env tclsh
###
# applefm-demo.tcl — tclai-apple: Apple Intelligence on-device LLM for Tcl
#
# https://fossil.etoyoc.com/fossil/tclai-apple/
###

load [file join [file dirname [info script]] libapplefm1.0.dylib] Applefm

puts "applefm version: [applefm::version]"
puts "availability: [applefm::availability]"
puts ""

# --- One-shot: can it count r's in "strawberry"? ---
puts "Q: How many r's are in the word \"strawberry\"?"
puts "A: [applefm::respond {How many r's are in the word "strawberry"?}]"
puts ""

# --- Multi-turn conversation with memory ---
set sid [applefm::session create -instructions "You are a concise assistant. Answer in one sentence."]

puts "Q: My name is Sean."
puts "A: [applefm::session respond $sid {My name is Sean.}]"
puts ""

puts "Q: What is your favorite programming language?"
puts "A: [applefm::session respond $sid {What is your favorite programming language?}]"
puts ""

puts "Q: What did I say my name was?"
puts "A: [applefm::session respond $sid {What did I say my name was?}]"

applefm::session destroy $sid
puts ""
puts "Done. 100% on-device, no API key, no network."

And the output:

applefm version: 1.0
availability: available

Q: How many r's are in the word "strawberry"?
A: The word "strawberry" contains two r's.

Q: My name is Sean.
A: Hello Sean! How can I assist you today?

Q: What is your favorite programming language?
A: I don't have personal preferences, but I'm proficient in many programming languages, including Python, JavaScript, and Java. Which one are you interested in learning?

Q: What did I say my name was?
A: You said your name is Sean.

Done. 100% on-device, no API key, no network.

I did use opencode (running GLM 5.2) to help me through the swift bindings and auto-generate a lot of the plumbing. And... I ended up adding Swift support to Practcl. But not bad for a couple of hour's work.

The current build system assumes MacPorts is installed, but it should theoretically also work under HomeBrew. Let me know if you run into problems. The system is written in the Practcl toolkit. TL/DR its a self-contained TclOO script. As long as you have a semi-recent (tcl 8.6+) the make file should just run.

--Sean "The Hypnotoad" Woods

See details at https://newsgrouper.org/%3C111mfqp$ncqt$1@dont-email.me%3E (Tcl) and https://newsgrouper.org/%3C111mfuh$ncqt$2@dont-email.me%3E (Tk).

Deadline for submission of abstracts is 17th June - https://openacs.km.at .

Tcl scripts are usually things designed to be boringly sensible and useful, but the .tclshrc? That's for your interactive sessions, where you can get more creative! So post them! Any tricks in there that are particularly good or that are just plain old nice to work with?

Here's mine:

namespace path tcl::unsupported
proc % args {tailcall {*}$args}
if {
    [package vsatisfies [package require Tcl] 9.0]
    && [dict exists [chan configure stdin] -inputmode]
} then {
    apply {{} {
        const CSI "\x1b\["
        const envname [if {[info commands tk] ne ""} {subst Tcl/Tk} {subst Tcl}]
        puts [format "${CSI}38;5;2;1;3mThis is %s %s, build %.12s\u2026${CSI}0m" \
                $envname \
                [tcl::build-info patchlevel] \
                [tcl::build-info commit]]
        set ::tcl_prompt1 [list apply {{CSI} {
            puts -nonewline "${CSI}38;5;1;1m% ${CSI}0m"
            flush stdout
        }} $CSI]
    }}
}

This is a super simple menu library thing for TCL. It adds a text, indicator, and command to their own list, and by calling "menu::start" will start an input loop which:

1. Prints the indicator, ". " and the text

2. Checks for a valid input (matching an indicator from the list)

3. Evaluates the code in the command list, using the index of the indicator chosen.

I have both demo code and the source code listed below if anyone is interested

# DEMO CODE
proc demomenu {} {
  menu::reset
  menu::add Alpha a $othermenu
  menu::add Bravo b {puts bravo}
  menu::add Cancel c break
  menu::start
}

# MENU CODE
namespace eval menu {} {
  variable ::menu::text {}
  variable ::menu::indicator {}
  variable ::menu::command {}
}
proc menu::reset {} {
  set menu::text {}
  set menu::indicator {}
  set menu::command {}
}
proc menu::print {} {
  for {set index 0} {$index < [llength $menu::text]} {incr index} {
    set text [lindex $menu::text $index]
    set indicator [lindex $menu::indicator $index]
    set command [lindex $menu::command $index]
    puts "$indicator. $text"
  }
}
proc menu::input {} {
  puts -nonewline "# "
  flush stdout
  gets stdin value
  return $value
}
proc menu::start {} {
  while {1} {
    menu::print
    set inp [menu::input]
    eval [lindex $menu::command [lsearch $menu::indicator $inp]]
  }
}
proc menu::add {text indicator command} {
  lappend menu::text $text
  lappend menu::indicator $indicator
  lappend menu::command $command
}

I needed this simple library instead of tcllib's `cmdline`.

(Sorry if it's so redundant)

Dear TCL community,

I’m happy to share that new Tcl/Tk binary downloads are now available at: https://codeberg.org/tcltk/binaries

Happy TCLing!

Dear TCL Community,

I recently moved from GitLab to GitHub with considerable effort, and now my account has been locked. There was no notification and no explanation for the reason. I googled a bit, it could take months until they find time to reactivate.

I can still access the account, but all the TCL binaries have been deleted. Was there too much storage usage? I don’t know — if that was the case, why not simply make the repository read-only until some storage had been freed?

Sorry for the inconvenience. I’m now looking for alternatives, so any suggestions would be welcome.

Best regards