tk_setPalette(3tk)

πŸ“¦
version 9.0.4 Β· 2 versions
, in debian trixie, ubuntu questing, ubuntu resolute, ubuntu stonking

πŸ’– tk_setPalette, tk_bisque β€” glow-up time for your Tk colors πŸ’–

okay bestie, so this is tk_setPalette(3tk) from the Tk Built-In Commands manual, and honestly? It's the makeover episode of the manpage world. Let's get into it. ✨


🌈 NAME 🌈

tk_setPalette, tk_bisque β€” modify the Tk color palette 🎨


πŸŽ€ SYNOPSIS πŸŽ€

tk_setPalette background
tk_setPalette name value ?name value ...?
tk_bisque

✨ DESCRIPTION ✨

The tk_setPalette procedure changes the color scheme for Tk. It pulls this off in two ways: by modifying the colors of existing widgets, and by changing the option database so that future widgets will use the new color scheme. Both. It's an overachiever, we love that. πŸ‘‘

If tk_setPalette is invoked with a single argument, that argument is the name of a color to use as the normal background color. Then tk_setPalette will compute a complete color palette from this background color. One color in, whole vibe out. πŸ’…

Alternatively, the arguments to tk_setPalette may consist of any number of name-value pairs, where the first argument of the pair is the name of an option in the Tk option database and the second argument is the new value to use for that option.

The following database names are currently supported:

  • activeBackground
  • activeForeground
  • background
  • disabledForeground
  • foreground
  • highlightBackground
  • highlightColor
  • insertBackground
  • selectBackground
  • selectColor
  • selectForeground
  • troughColor

tk_setPalette tries to compute reasonable defaults for any options that you do not specify. And plot twist: you can specify options other than the above ones and Tk will change those options on widgets as well. This feature may be useful if you are using custom widgets with additional color options. Not me giving you permission to go off-script. πŸ™ˆ

Once it has computed the new value to use for each of the color options, tk_setPalette scans the widget hierarchy to modify the options of all existing widgets. For each widget, it checks to see if any of the above options is defined for the widget. If so, and if the option's current value is the default, then the value is changed; if the option has a value other than the default, tk_setPalette will not change it. Respectful. It knows better than to touch your custom choices. 🫢

The default for an option is the one provided by the widget:

[lindex [$w configure $option] 3]

...unless tk_setPalette has been run previously, in which case it is the value specified in the previous invocation of tk_setPalette. So yeah, it remembers what it did last time. Memory like an elephant, skin like glass. πŸͺž

After modifying all the widgets in the application, tk_setPalette adds options to the option database to change the defaults for widgets created in the future. The new options are added at priority widgetDefault, so they will be overridden by options from the .Xdefaults file or options specified on the command-line that creates a widget. So it's a suggestion, not a decree. The .Xdefaults file stays the main character there. πŸ“

🌸 Heads up: the priority is literally widgetDefault, so if something else outranks it, it wins. That's not a bug, that's the whole point.

The procedure tk_bisque is provided for backward compatibility: it restores the application's colors to the light brown ("bisque") color scheme used in Tk 3.6 and earlier versions. Retro moment. Vintage. Antique-core. πŸŽ€


πŸ‘‘ KEYWORDS πŸ‘‘

bisque, color, palette


okay that's the whole page, bestie β€” go forth and recolor. This was Tk 4.0, page tk_setPalette(3tk), and there's genuinely no date field on this footer so I'm not making one up, that's a you-and-the-version thing. slay, bye! πŸ’œπŸ¦‹βœ¨

πŸ“¦ where this page comes from