DN577901267

Subject: Re: option database confusion - DN [1]

dminer@edison.chisp.net (Dan Miner) - 26 Jan 2000 - comp.lang.tcl

 In article <c%8j4.438$m5.3757458@news-read1.qis.net> you wrote:

 : proc save_options {} {
 :     set color [.body.text cget -background]
 :     set fp [open browser.def w]
 :     puts $fp "*background: $color"
 :     close $fp
 : }

 : proc load_options {} {
 :      option readfile browser.def
 : }
 : load_options

 : after which the actual widgets are created. Am I correct that the option
 : file needs to be loaded before widgets are created in order to have any
 : effect?

 Yes, you must set up the option database before creating any widgets.  The
 only gotcha is the . window since it's already create by the time you can
 execute any statements.  To fix this, try somthing like

     . configure -background [option get . background Background]

 : The above seems to work with *background, which is much more general than I
 : want, but I haven't had much luck trying for more. Should it be possible for
 : me to specify an individual widget (.body.text.background: blue), or at
 : least widgets within a specific frame, in this kind of resource file? It
 : doesn't seem to work. In the larger program that I'd like to use this for,
 : users should be able to set contrasting colors for different text widgets,
 : etc., and I'm having trouble figuring out how to get that specific.

 The option database is actually a X Window creature.  Briefly, there are
 two types of "options" -- option name and option class.  Think of these
 as you're level of interest in changing a widget's specific option.  An
 option class is very broad and can set your preference for many specific
 options.  Now, you can get even more specific about which widgets you
 wish to configure via options.  This is where the widget's name and class
 name come into play.  For example:

 [you *must* name the file: example]
 option add *background blue
 option add Example.f0.background black

 frame .f0
 frame .f0.f0
 . configure -background [option get . background Background]
 pack .f0.f0 -ipadx 100 -ipady 100 -padx 10 -pady 10
 pack .f0 -ipadx 100 -ipady 100 -padx 10 -pady 10

 You should get a look of blue bordered black window with a blue square
 near the top.  [Note: this is how it looks..]

 In this example, the second option command is *very* specific by
 naming the application class and the widget name.

 For further details, read the man page on option
 [UNIX,  man n option   or man -s n option   usually]

 Generally, you want to only set a specific type (aka class) of
 widget.  For example:

 [BTW, I would *never* use this set of colors.. :)]

 # by default, all options in the Background class
 option add *Background grey50
 # by default, all options in the Foreground class
 option add *Foreground black

 # These widgets are different -- higher interactivity with user
 option add *Listbox.Background white
 option add *Listbox.Foreground black
 option add *Text.Background white
 option add *Text.Foreground black
 option add *Entry.Background white
 option add *Entry.Foreground black

 # Note.. You can not use the option database this way to override the
 # default black color on canvas items (text, lines, etc.)
 # This has been IMHO a long outstanding bug

 : Also--the program currently has widget colors hard-wired in the source code.
 : If I load an option file, and then create widgets with colors specified,
 : those later colors will override what the option file says, right? That
 : seemed to be what was happening in one of my failed experiments. I'd like to
 : be able to supply default colors (the current ones) for users who haven't
 : created a configuration file, instead of just removing all colors from the
 : main program.

 Yes, configuration option (-whatever) override/hardcode the color.  It
 is *much* better to use the option database since it is easy to
 customize and usually can be done in one place.  In fact, you can create
 ways of doing non-widget options.

 option add *CustOption.myoption  testing
 frame .dummy -class CustOption

 puts stdout [option get .dummy myoption myoption]

 [output is *drum roll*:  testing]

 : And another question: I'd also like to be able to store variable values, as
 : well as widget options, in a configuration file (e.g., a variable that turns
 : a certain behavior on or off). Is this possible?

 Yes.. see above.. :)

 : I'm wondering whether it might not be simpler just to write ".widget
 : configure -bg red" commands or whatever to a .tcl file and then source
 : that...

 IMHO, no.  I have this problem constantly.  I can not tolerate bright
 colors and I have to do *major* editing on Tcl programs to find all
 of these hard coding jobs.  [For example, freeDelivery -- it took
 45 minutes to remove it all.]  To make matters worst, people only
 hard code small parts of the program.  So my options take effect on
 most of the application but not all.  Still worse, they hardcode the
 background and ignore the foreground (look at some tooltip modules!).

 Now, a file with variables of colors that is source'ed and these variables
 are used is a decent compromise but you *must* be ocmplete.  Never
 forget an option's partner (background/foreground,
 selectbackground/selectforeground, etc).

 Hope this helps.

         Dan

 --
  Dan Miner     dan@miner.org |   "That vulnerability is completely    | Doing
         Linux & UNIX         |      theoretical." -- Microsoft        | Linux
     Programmer/Consultant    | "What yonder light Windows 95 breaks?" | since
   http://www.dan.miner.org/  |    "Free software: The New Frontier"   | v0.12
 ------------------------------------------------------------------------------
        By filing this bug report, you have challenged the honor of my
        family.  PREPARE TO DIE!