itclvars(3itcl)

💖 NAME 💖

itclvars — this is a 3itcl manual page, bestie, and it's all about the variables that [incr Tcl] uses 🫶

---

✨ DESCRIPTION ✨

Okay so listen 👑 — [incr Tcl] is out here creating and managing a whole little squad of global variables all by itself, automatically, no input from you. And unless the page says otherwise down below, the vibe is: these are read-only for your application-specific code AND for users. So look, don't touch, iykyk 💅

---

🌸 itcl::library 🌸

The moment an interpreter gets created, [incr Tcl] sets this variable to hold the name of a directory — specifically the one containing the system library of [incr Tcl] scripts 📁✨

And where does that initial value come from? Great question. It's pulled from the ITCL_LIBRARY environment variable if that thing exists, or from a compiled-in value otherwise. Fr fr, that's it.

---

🎀 itcl::patchLevel 🎀

When an interpreter is created, [incr Tcl] initializes this one to hold the current patch level for [incr Tcl] 🩹

Like, for example: a value of "2.0p1" means [incr Tcl] version 2.0 with the first set of patches applied. Slay, now you can read version strings like a pro.

---

🦋 itcl::purist 🦋

Ooh okay, this one's the drama ✨ When an interpreter is created containing Tcl/Tk and the [incr Tcl] namespace facility, this variable controls a "backward-compatibility" mode for widget access.

Here's the lore 📖 In vanilla Tcl/Tk there's just one single pool of commands, so the access command for a widget is the exact same thing as the window name. Simple. But the second a widget gets created inside a namespace? Its access command gets installed in that namespace, and you're supposed to reach it from outside using a qualified name. Like this:

namespace foo {
    namespace bar {
        button .b -text "Testing"
    }
}
foo::bar::.b configure -background red
pack .b

So notice 👀 — the window name ".b" is still the one you use with commands like pack and destroy. But the access command for the widget (aka the name that shows up as the first argument on a command line) has to be more specific. Periodt.

Now, the "winfo command" command can be used to query the fully-qualified access command for any widget, so you can write:

[winfo command .b] configure -background red

...and honestly? That's good practice when you're writing library procedures. Chef's kiss 👨‍🍳💋 Also, in conjunction with the bind command, the "%q" field can be used in place of "%W" as the access command:

bind Button <Key-Return> {%q flash; %q invoke}

But here's the tea 😭 While this behavior makes total sense from the standpoint of encapsulation, it causes problems with existing Tcl/Tk applications. Many existing applications are written with bindings that use "%W". And many library procedures just assume that the window name is the access command. Awkward.

So itcl::purist controls a backward-compatibility mode:

• By default, this variable is "0", and the window name can be used as an access command in any context. Whenever the unknown procedure stumbles across a widget name, it simply uses "winfo command" to figure out the appropriate command name. Chill vibes, no stress.
• If you set this variable to "1", that backward-compatibility mode is disabled. You get better encapsulation, but using the window name as the access command may lead to "invalid command" errors 💀

So like, choose your fighter. Better encapsulation vs. stuff not breaking. No cap.

---

🌈 itcl::version 🌈

When an interpreter is created, [incr Tcl] initializes this variable to hold the version number, in the form x.y ⭐

Changes to x represent major changes with probable incompatibilities 😬 and changes to y represent small enhancements and bug fixes that retain backward compatibility 🥰 So x is the main character energy and y is the supportive bestie.

---

🍓 KEYWORDS 🍓

itcl, variables

---

and that's the whole page, bestie!! 🎀 this was itcl version 3.0, straight out of the itclvars(3itcl) manual page — love u, go treat those variables as read-only ok bye 💜🧚✨