Regarding only the last widget getting a name, rather than doing
something like:
> STk> (define f (make <Frame>))
> #[undefined]
> STk> (Id f)
> #[Tk-command .v232]
> STk> (define g (make <Button> :parent f :Id "foo"))
> #[undefined]
> STk> (Id g)
> #[Tk-command .v232.foo]
you'd do:
STk> (define f (make <Frame> :Id "bar"))
#[undefined]
STk> (Id f)
#[Tk-command .bar]
STk> (define g (make <Button> :parent f :Id "foo"))
#[undefined]
STk> (Id g)
#[Tk-command .bar.foo]
Then you'd configure g by specifying X defaults as
STk*bar.foo.background: red
for example.
So, when making use of this :Id keyword for configuration, you'd have
to use it from the top of the hierarchy containing widgets which you
want to configure. I don't see this as a problem, and it fits nicely
into Tk's automatic handling of X resources.
Also, the point I was trying to get at in my previous message on the
subject was that one might want to use the same mechanism for
arbitrary object slots instead of just one's associated with a widget.
For example, if I have a class <foo> that inherits from <rectangle>
and has two additional slots phase and flavor, I might want to allow
phase and flavor to also be user configurable via X resources.
For this, it might be nice to have something like (flavor
:init-from-environment #t) be in the list of slots when defining the
class. This would say that when a <foo> is instantiated, it's flavor
slot should be unbound, unless there's an X resource specifying it's
value, in which case the X resource's value should be used. If one
uses :initform and :init-from-environment, I'd think that the
environment value should override the initform if the X resource
exists.
--
Dr. Harvey J. Stein
Berger Financial Research
abel_at_netvision.net.il
Received on Wed Sep 11 1996 - 12:09:18 CEST