The Tk command '''option''' acts on the "[option database]".
<<br>>
http://purl.org/tcl/home/man/tcl8.5/TkCmd/option.htm

    :   '''[option add]''' ''pattern value'' ?''priority''?
    :   '''[option clear]'''
    :   '''[option get]''' ''window name class''
    :   '''[option readfile]''' ''fileName'' ?''priority''?

The ''priority'' should normally be one of '''widgetDefault''', '''startupFile''', '''userDefault''', or '''interactive'''. If ''priority'' is omitted, it always defaults to '''interactive''' (the highest level).

<<discussion>>

[Chris Nelson] notes:

 > I've changed to:
 > 
 >    # Why do these affect selection?
 >    option add *Entry.background red widgetDefault
 >    option add *Entry.foreground blue widgetDefault
 > 
 >    entry .e
 >    pack .e
 > 
 >    # Why is this only when the button is active?
 >    option add *Button.background red widgetDefault
 >    option add *Button.foreground green widgetDefault
 > 
 >    button .b -text Exit -command exit
 >    pack .b
 > 
 > And now the options seem to have no effect.

Based on a clue from Jeff in another conversation, I found that setting
the priority to startupFile, instead of widgetDefault, was enough to get
this to work.  It seems Solaris' CDE does some funky color stuff.

----

Jeff replies:

More accurately, Solaris sets the equivalent of:
        *foreground
 and    *background

in the X defaults.  Very lame way to control L&F, but that's
what they chose.  Those wanting to get around this can also
see the solutions in the Tk Usage FAQ:
        http://www.purl.org/net/hobbs/tcl/faqs/tk/
        (aka http://tcl.sourceforge.net/faqs/tk/ )

''[DKF] notes:''
For toolkits based on Xt (such as Athena, Motif and CDE) the above settings are not quite so lame.  That's because the rule there is to choose the "most specific" option, and therefore those options listed above are overridden by virtually everything.  It's just that Tk's option-db handling code does things ''quite'' differently...

[LV] So why does Tk do things so differently?  Why not do them in a way that is compatible with Xt, at least on platforms where Xt is used?  And is there a way to code option calls so that one gets the equivalent of the Xt method of resolving resources - that is, to choose the most specific resource database entry?

----

[Example of using option to allow various levels of configurability]


[DKF]: There is a tutorial on option use in [http://www.cs.man.ac.uk/~fellowsd/tcl/option-tutorial.html%|%my personal web pages].
----

[LV] I'd like to find out what the default font resource for a widget is without creating the widget.  It seems like '''option get''' would be the way to do this but I can't figure out exactly what I need to pass.  I'm trying stuff like
  option get . *.label.font {}
and I get nothing.  Does anyone have an example that would work?

[GPS]: You can't.  You need the item in the resource database.  Tk has hardcoded defaults for label.  It would probably have been a better design to set a widgetDefault option for the fonts, and colors, but Tk doesn't do that. 

Labels are implemented in the button code, so I did some grepping and found that DEF_BUTTON_FONT is used. 

 $ grep -r DEF_BUTTON_FONT *
 generic/tkButton.c:     DEF_BUTTON_FONT, -1, Tk_Offset(TkButton, tkfont), 0, 0, 0},
 generic/tkButton.c:     DEF_BUTTON_FONT, -1, Tk_Offset(TkButton, tkfont), 0, 0, 0},
 generic/tkButton.c:     DEF_BUTTON_FONT, -1, Tk_Offset(TkButton, tkfont), 0, 0, 0},
 generic/tkButton.c:     DEF_BUTTON_FONT, -1, Tk_Offset(TkButton, tkfont), 0, 0, 0},
 macosx/tkMacOSXDefault.h:#define DEF_BUTTON_FONT                        "system"
 unix/tkUnixDefault.h:#define DEF_BUTTON_FONT                    BOLD_FONT
 win/tkWinDefault.h:#define DEF_BUTTON_FONT              CTL_FONT

Well, I'm a unix nerd, so I am curious about BOLD_FONT.  Here we go:
 $ grep -r BOLD_FONT *
 unix/tkUnixDefault.h: * BOLD_FONT -             Bold font 
 unix/tkUnixDefault.h:#  define  BOLD_FONT       "sans-serif -12 bold"
 unix/tkUnixDefault.h:#  define  BOLD_FONT       "Helvetica -12 bold"
 unix/tkUnixDefault.h:#define DEF_BUTTON_FONT                    BOLD_FONT
 unix/tkUnixDefault.h:#define DEF_LABELFRAME_FONT                BOLD_FONT
 unix/tkUnixDefault.h:#define DEF_LISTBOX_FONT           BOLD_FONT
 unix/tkUnixDefault.h:#define DEF_MENU_FONT                      BOLD_FONT
 unix/tkUnixDefault.h:#define DEF_MENUBUTTON_FONT                BOLD_FONT
 unix/tkUnixDefault.h:#define DEF_MESSAGE_FONT           BOLD_FONT
 unix/tkUnixDefault.h:#define DEF_SCALE_FONT                     BOLD_FONT

[LV] Any Tk experts know if there would be fatal consequences of changing Tk to use the
option database for these sorts of things?

----
'''[WHD] - 2009-10-27 14:04:17'''

The color scheme for the Ttk widgets comes from the chosen theme; the option database is not consulted.  The color scheme for the standard Tk widgets comes from the option database.  This can result in weird looking GUIs where things like menus are entirely the wrong color.

   * Is there a way to prevent Tk from looking at the option database at all?
   * Would it be appropriate (in Tk 9, say) to make the option database have effect only on demand?

<<discussion>>

<<categories>> Tk syntax help | Arts and crafts of Tcl-Tk programming | Command | Tk