Starting with Tcl/Tk 8.5, a entire new window set, formerly known as Tile was incorporated into Tcl/Tk.

Tile, is a so-called theming engine. That is windows originating from Tile may change their appearance in response to a »ThemeChanged« event. A Tile window does no longer feature properties dedicated to the visual appearance, except for a entire new »style« property.

Tile itself resides in its own »ttk« namespace. Tk’s namespace is »tk«, but the Tk window commands are being exported into the global namespace.

The Tile window commands are identical named to their Tk counterparts.

#  ➊ Global namespace:
    button .b -text "a button generated"

#  ➋ Tk’s namespace:
tk::button .tkb -text "another button"

The two buttons in Example 7.11, “button versus tk::button”, are both created by »tk::button«. The first form only deploys the imported form.

# Tile is bundled with Tk version 8.5
package require Tk 8.5

# Export the ttk::button.
namespace inscope ttk {
  namespace export button
}

# Brute force import the ttk::button.
namespace import -force ::ttk::button

#  ➊
button .b -text "a ttk-button generated"

#  ➋
ttk::button .ttkb -text "another ttk-button"

A Tcl/Tk application, capable to deploy Tile or plain Tk must store every property, were Tk and Ttk differ, inside the Option Database. Jeszra provides a Tile dedicated resource set, listing these properties: (Figure 7.1, “Preferences: Option DB” ).

Unknown or erroneous Option Database properties are gracefully ignored by every window unaware of it.

The template is tied to a specific window type for each specific property, either from Tile such as style or Tk such as background, when the property is published in the template interface.

The obvious solution, to avoid a broken interface, as in Example 7.13, “Published Background”, is to not include these properties in the template interface. There is a better solution available. The Runtime Library template mechanism does detect when an broken interface property is encountered and ignores the errors stemming from it. This workaround addresses the writing to properties.

Reading from the template interface requires a more sophisticated approach. The underlying technique is called inoculation. I described the inoculation technique in: Runtime Library themed ff. After inoculating a template interface, the contained windows, partake on theme changes. These theme changes are pipelined through the template interface, from which it is distributed to its elements. Even plain Tk windows are thus theme able. The template doesn’t even need a single Tile element for using themes!

Tile isn’t used by Jeszra, hence there is no default palette dedicated to Tile.

proc dumper::screenshot { type target } {}

# Window classes already
# registered to use »screenshot«:
vgcode::register-screenshot \
   TButton     TRadiobutton TCheckbutton \
   TMenubutton Spinbox      TNotebook \
   Radiobutton Checkbutton  Menubutton

The Figure 7.6, “Substitution Preferences” displays a mapping table for certain window classes. The first column in »Substitute with« shows the assumed creator for a certain window class, and second what must be used instead. All Tile window classes are listed here. The mapping includes the Tile namespace »ttk«. For windows fo class »TMenubutton« »ttk::menubutton« is being used.

Other window classes are listed as well. A hugelist window, for example, is created through the command »hugelist::create«.

Substitutions may occur for any window class. The pair »Button tk::button«, for example adds the namespace »tk« to each button creation code. Resembling the second case in Example 7.11, “button versus tk::button”.

Figure 7.6. Substitution Preferences