Tcl - label prevents from unsetting a variable

Author

label prevents from unsetting a variable - bug or feature?

Jan Harnisch

2005-02-17, 8:59 pm

Hi guys,

today, I observed a somewhat strange behaviour (Linux, Tcl/Tk 8.4.6):
First, I start up wish and create a simple label:

~$ wish
% label .l -textvariable testvar
..l
% pack .l

OK, so it is possible to create a label displaying a variable that is
not yet set. That`s fine with me.

% set testvar 42
42

....now the label displays my variable. So far, so good.

% unset testvar

....but now, the label _still_ displays the variable. And it is still
set, although unset did not complain:

% set testvar
42

So it seems to me that, as soon as I have a label displaying a variable,
it is not any more possible to unset this variable. Is this the intended
behaviour (and is it documented somewhere?) or is it simply a bug?
Greetings & Thanks,

Jan

--
My From: address is valid, but for email please use Reply To:
The Reply To: address is valid without modification.

Jeff Hobbs

2005-02-17, 8:59 pm

Jan Harnisch wrote:
> today, I observed a somewhat strange behaviour (Linux, Tcl/Tk 8.4.6):
> First, I start up wish and create a simple label:
...
> OK, so it is possible to create a label displaying a variable that is
> not yet set. That`s fine with me.
...
> ...now the label displays my variable. So far, so good.
...
> ...but now, the label _still_ displays the variable. And it is still
> set, although unset did not complain:

That is all 100% correct and expected with -textvariables,
whether on the label or the entry. In order to do that sync
of values, they create a trace at the C level, on unsets as
well (which recreate the var). That is required for them to
operate, quite simply. There is no error in unsetting, the
label is just doing it's job post-unset of recreating its
link to the variable, as you requested -textvar to do.

--
Jeff Hobbs, The Tcl Guy
http://www.ActiveState.com/, a division of Sophos

Jan Harnisch

2005-02-17, 8:59 pm

Hi Jeff,

thanks for your quick reply!
Bye,

Jan

--
My From: address is valid, but for email please use Reply To:
The Reply To: address is valid without modification.

Schelte Bron

2005-02-18, 4:00 pm

On 02/17/05 22:47, Jeff Hobbs wrote:
> That is all 100% correct and expected with -textvariables,
> whether on the label or the entry. In order to do that sync
> of values, they create a trace at the C level, on unsets as
> well (which recreate the var). That is required for them to
> operate, quite simply. There is no error in unsetting, the
> label is just doing it's job post-unset of recreating its
> link to the variable, as you requested -textvar to do.
>
Note that this philosophy has changed with tile. A tile widget does not
automatically create the variable specified by the -textvariable option.

Schelte.
--
set Reply-To [string map {nospam schelte} $header(From)]

Jeff Hobbs

2005-02-18, 8:57 pm

Schelte Bron wrote:
> On 02/17/05 22:47, Jeff Hobbs wrote:
>
> Note that this philosophy has changed with tile. A tile widget does not
> automatically create the variable specified by the -textvariable option.

I would argue that this is a bug in tile. Tile is intended
to affect visual display, not the underlying behavior. At
this time, a lot of code is duplicated into tile to make it
work as a separate extension. A lot of this would disappear
when it becomes a core component, which would address most
of the behavioral discrepancies.

--
Jeff Hobbs, The Tcl Guy
http://www.ActiveState.com/, a division of Sophos

Joe English

2005-02-19, 3:58 am

Jeff Hobbs wrote:
>Schelte Bron wrote:
>
>I would argue that this is a bug in tile.

I would argue that this is a bug in the core widgets :-)

Actually the behaviour described above is the same in tile --
the -textvariable always exists, due to the trace. What has changed,
though, is the behavior of [$w configure -textvariable $var]
when $var is currently unset.

In the core widgets, after [$w configure -textvariable V],
[$w cget -text] will be set to the value of $V, _unless_ V
is currently unset, in which case V is automagically initialized
to the current value of [$w cget -text]. In the tile widgets,
the -textvariable always takes precedence if set. That is,
data only flows in one direction.

All of the linked -*variable options currently follow the
same convention, although I'm considering making an exception
for the ttk::checkbutton -variable option (in this case
it sort of makes sense to automagically initialize the
linked -variable, and it turns out that a lot of existing
code depends on this behaviour).

> Tile is intended
>to affect visual display, not the underlying behavior. At
>this time, a lot of code is duplicated into tile to make it
>work as a separate extension.

Not that much code is duplicated, actually -- most of the
tile widgets were rewritten from scratch (the main exception
being the ttk::entry widget, and even that's been heavily
refactored).

The tile code is also quite a bit simpler than the core widgets.
This is partly because the theme engine makes a lot of things
easier (all the grotty details of widget display and much of
the platform-specific code is abstracted away), and partly
because much of the boilerplate code has been factored out
into a separate framework.

> A lot of this would disappear
>when it becomes a core component, which would address most
>of the behavioral discrepancies.

--Joe English

Jeff Hobbs

2005-02-19, 3:58 pm

Joe English wrote:
> Jeff Hobbs wrote:
>
>
> I would argue that this is a bug in the core widgets :-)

I guarantee you that you will lose that argument. ;)
Whether by logic or by simple convention, in this kind of case,
the core is simply by definition "correct".

> In the core widgets, after [$w configure -textvariable V],
> [$w cget -text] will be set to the value of $V, _unless_ V
> is currently unset, in which case V is automagically initialized
> to the current value of [$w cget -text]. In the tile widgets,
> the -textvariable always takes precedence if set. That is,
> data only flows in one direction.
>
> All of the linked -*variable options currently follow the
> same convention, although I'm considering making an exception
> for the ttk::checkbutton -variable option (in this case
> it sort of makes sense to automagically initialize the
> linked -variable, and it turns out that a lot of existing
> code depends on this behaviour).

I don't see how you logically justify the behavior to not set
a currently unset var in all cases.

> The tile code is also quite a bit simpler than the core widgets.
> This is partly because the theme engine makes a lot of things
> easier (all the grotty details of widget display and much of
> the platform-specific code is abstracted away), and partly
> because much of the boilerplate code has been factored out
> into a separate framework.

It also surfaces with the simplest widgets, and still, some of
those that it does surface have introduced subtle
incompatabilities like that noted above that I think need to
be prevented. Stuff dealing with visual (option handling,
color and font management, etc) will be different (that is the
point of Tile, after all), but I don't see grounds for
changing underlying behavior that isn't contentious in its
current form.

--
Jeff Hobbs, The Tcl Guy
http://www.ActiveState.com/, a division of Sophos

Schelte Bron

2005-02-22, 4:02 pm

On 02/19/05 02:10, Joe English wrote:
> Actually the behaviour described above is the same in tile --
> the -textvariable always exists, due to the trace. What has changed,
> though, is the behavior of [$w configure -textvariable $var]
> when $var is currently unset.
>
> In the core widgets, after [$w configure -textvariable V],
> [$w cget -text] will be set to the value of $V, _unless_ V
> is currently unset, in which case V is automagically initialized
> to the current value of [$w cget -text]. In the tile widgets,
> the -textvariable always takes precedence if set. That is,
> data only flows in one direction.
>

I read that as if the tile widgets will also create the variable given
to the -textvariable option. It will just not initialize it to the
current value of the -text option. However that is not what I see when I
do some experiments:

### Tile
% package require tile
0.5
% ttk::label .l1 -textvariable str1
..l1
% set str1
can't read "str1": no such variable
% set str1 foo
foo
% unset str1
% set str1
can't read "str1": no such variable

### Regular Tcl/Tk
% label .l2 -textvariable str2
..l2
% set str2
% set str2 bar
bar
% unset str2
% set str2
bar

What am I misunderstanding?

Schelte.
--
set Reply-To [string map {nospam schelte} $header(From)]

Jeff Hobbs

2005-02-22, 9:00 pm

Schelte Bron wrote:
> On 02/19/05 02:10, Joe English wrote:
>
>
> I read that as if the tile widgets will also create the variable given
> to the -textvariable option. It will just not initialize it to the
> current value of the -text option. However that is not what I see when I
> do some experiments:

You misread that - the tile widgets will *not* instantiate the
variable, with either a null value or the current value, as
you found in your experimentation. That is what's wrong, as
it is an (IMO) illogical and/or unnecessary incompatability.

--
Jeff Hobbs, The Tcl Guy
http://www.ActiveState.com/, a division of Sophos

Sponsored Links